У меня около 100 000 строк общих данных. Столбцы/Свойства этих данных определяются пользователем и имеют обычные типы данных (строка, int, double, date). Будет около 50 столбцов/свойств.
У меня есть 2 потребности:
например Column3 = Column1 * Column2.
В конечном счете, я хотел бы иметь возможность использовать внешние данные с помощью обратного вызова, например, Column3 = Column1 * GetTemperature
Выражение относительно просто, операции maths, sum, count и IF являются единственными необходимыми функциями.
Чтобы иметь возможность фильтровать/группировать данные и выполнять агрегации
например Сумма (Data.Column1) Где (Data.Column2 == "blah" )
Насколько я вижу, у меня есть два варианта:
1. Использование DataTable.
= > Точка 1 выше достигается с помощью DataColumn.Expression
= > Точка 2 выше достигается с помощью DataTable.DefaultView.RowFilter или DataTable.Select() и кода С#
2. Использование списка общих объектов, каждый с Dictionary < string, object > , чтобы сохранить значения.
= > Точка 1 может быть достигнута чем-то вроде NCalc
= > Точка 2 достигается с помощью LINQ
DataTable: Pros: DataColumn.Expression is inbuilt Cons: RowFilter & coding c# is not as "nice" as LINQ, DataColumn.Expression does not support callbacks(?) => workaround could be to get & replace external value when creating the calculated column GenericList: Pros: LINQ syntax, NCalc supports callbacks Cons: Implementing NCalc/generic calc engine
Исходя из вышеизложенного, я бы подумал, что подход GenericList победит, но что-то, что я не учитывал, - это производительность, которая по какой-то причине, я думаю, была бы лучше с datatable.
У кого-нибудь есть ощущение/опыт работы с продукцией LINQ и DataTable?
Как насчет NCalc?
Как я уже сказал, есть около 100 000 строк данных с 50 столбцами, из которых, возможно, 20 вычисляются.
В общей сложности около 50 правил будут выполняться против данных, поэтому в общей сложности будет проведено 5 миллионов сканирования строк/объектов.
Был бы очень признателен за любые идеи. спасибо.
пс. Конечно, использование базы данных + SQL и представлений и т.д. Было бы самым простым решением, но по разным причинам не может быть реализовано.