Linq с DataTables против простого SQL

Question

Я работаю над приложением, которое генерирует отчеты, которые в основном стандартные операции SQL (сумма/средние на данных, сгруппированных по A/B, где X = Y и т.д.)

частей запрос может быть определен пользователем во время выполнения. как реализовано, необработанные данные находятся в DataTable, и я «анализирую» параметры запроса в выражении linq (в основном, овые операнды сопоставляются именам столбцов DataTable). он отличный и все, и не так много работы, но я не совсем уверен, почему я не просто помещаю данные в таблицу SQLite и просто использую фактический SQL, а просто создаю строки запроса из ввода пользователя.

Я знаю, что это довольно широко, но есть ли какое-то преимущество, которое я сейчас упускаю, поскольку по линии может оказаться, что linq станет лучшим выбором реализации? единственное, что приходит в голову, это то, что если я по какой-то причине хочу выйти за пределы DataTable в свои собственные классы, я все равно могу использовать linq для их запроса.

Answer 1

Вы можете поместить данные в данные SQLite и использовать фактический SQL. Я лично считаю, что единственной причиной для кода рефакторинга по этой причине является объем памяти. Если объем данных огромен (достаточно большой, он попадает в кучу больших объектов), вы можете не захотеть удерживать его в памяти в течение длительных периодов времени. В противном случае нет причин для этого маршрута, работа с информацией в памяти всегда быстрее, чем доступ к информации с диска. В противном случае я не вижу причин, чтобы удалить работу, которую вы сделали с LINQ, и переделать все это с помощью SQL и SQLite-файла.

Answer 2

Похоже, у вас уже есть хорошее решение.

Если вы хотите, чтобы перейти к SQLite, думать о других преимуществах, например, сохранение на диск, транзакции и т.д.

Или лучшее из обоих миров: LINQ над Sqlite (? Я полагаю, что это возможно)

Answer 3

"the only thing that comes to mind is that if I want to move beyond a DataTable to my own classes for some reason, I can still use linq to query them"

Это очень хорошая причина сама по себе. Ваше приложение получает определенную степень независимости языка от того, чтобы не привязываться непосредственно к sql. Если вы когда-нибудь захотите изменить хранилище данных/резервное копирование, вам будет намного легче.

Предполагая, что ваш синтаксический анализ является прочным, еще одно преимущество, которое вы получаете через код приложения с помощью LINQ, состоит в том, что он строго типизирован и менее хрупкий, чем строки sql.

Возможно, вы не считали это или не очень важным, но, подвергая LINQ, вы создаете более дружественный слой для работы.

Как и было предложено, вы можете поместить свои данные в SQLite и по-прежнему использовать LINQ. Вы можете получить коннекторы как для структуры сущности, так и для LinqToSql, а затем есть библиотеки, такие как dbLinq.

Если вы можете анализировать свои динамические запросы в linq, а затем предоставить провайдер linq перевести это в код базы данных underyling, то вы отвлечете свое приложение от технологий и вариантов инфраструктуры, которые могут показаться хорошими сейчас, но могут быть неуместными в будущем. Вы уже заявили, что собираетесь переходить на SQLite.

Как и во всех абстракциях, хотя это зависит от ваших приоритетов и того, с чем вам приходится жить (или без), который определяет, важны ли дополнительные слои абстракций.