@AleksyVB

Опишу ситуацию, есть БД с несколькими таблицами, с которыми нужно совершать много разных операций при разных условиях. Операции стандартные, но имена таблиц и критерии поиска часто разные.

Я создал класс с несколькими типовыми процедурами, в которые передаю параметры запроса.
Простой пример запроса: , этот запрос формируется так:
Такой один запрос я могу использовать практически для любых выборок из разных таблиц, вплоть до увеличения количества условий, просто передавая разные строковые параметры в процедуру, в которой выполняется запрос.

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

Возможно хуже читаемость запросов, но размер кода существенно меньше, чем плоха конкатенация SQL запроса помимо уязвимости SQL injection?

Думал попробовать Linq, но не нашел пока особого смысла, Linq to DataSet - надо сначала получать объекты DataTable, а потом из них уже делать выборку, но так как данные в таблицах часто меняются - придется постоянно поддерживать DataTable обновленными... Linq to SQL - база данных SQLite и для работы с Linq нужно создавать для каждой таблице по классу с атрибутами [DataTable] и [DataColumn], насколько я понял.

0

@DataPlanner

1. Тем, что макароны
2. Количество операций программы должно быть ограничено

0

@AleksyVB

Программа - бюджетов доходов и расходов, с пользователями, центрами затрат, статьями и субстатьями, планом по статьям и фактом по статьям, так что тут не ограничится)

0

@Grossmeister

Видимо зависит от СУБД.
Скажу на примере Oracle. Там есть кэш запросов, в который помещаются те запросы, которые уже использовались. Если приходит очередной запрос, то сначала он ищется в кэше и если такой найден, то он повторно используется. При этом экономится время на разбор запроса и построение плана выполнения (при большом числе запросов это м.б. весьма существенно).
Если мы формируем запрос динамически (dynamic SQL, по твоей терминологии - "конкатенация SQL"), то такой запрос повторно не используется, т.е. производительность сервера БД ухудшается. Поэтому в Oracle рекомендуется использовать dynamic SQL по минимуму, там, где без него просто не обойтись.
То же самое касается применение параметров в части WHERE вместо литералов.

0