Хранить запросы в C # или использовать хранимые функции в Postgres?

Question

Должен ли я хранить необработанные запросы SQL в своем коде на c # или делегировать их хранимым функциям в бэкэнде Postgres?

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

Влияет ли использование хранимых функций на возможность развертывания / обновляемости приложения?

Спасибо

Answer 1

Как правило, все наши взаимодействия с базой данных мы выполняем с помощью хранимых процедур вместо прямых операторов SQL; это дает большую гибкость для адаптации к изменениям схемы и проблемам производительности без необходимости перестраивать или повторно развертывать двоичные образы или файлы конфигурации для всех целей.

Answer 2

Мне очень нравится хранить SQL в текстовых файлах, встроенных в сборку как ресурсы (когда у меня есть , чтобы иметь значительное их количество; обычно я человек ORM).

Конечно, от вас зависит форматирование этого текстового файла. Вы могли бы иметь разделитель на две строки:

UpdateCustomer:
UPDATE CUSTOMER SET NAME=@Name WHERE ID=@ID

FindCustomer:
SELECT NAME, ADDRESS FROM CUSTOMER
WHERE ID=@Id

etc

Нетрудно иметь класс, который загружает его в Dictionary<string,string> в инициализаторе типа или даже в Dictionary<string,SqlStatementHelper>, где последний является классом, чтобы упростить подготовку оператора с соответствующими значениями. Вы можете использовать любой другой формат, который вы хотите, включая XML - хотя, если вам больше ничего не нужно, кроме пар имя / sql, это, вероятно, будет излишним.

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

Смешанное благословение хранимых проков в том, что они живут в базе данных, а не в вашем коде. Плюсом этого является то, что вы, скорее всего, будете синхронизировать их с изменениями DDL. Недостатком является то, что они требуют больше усилий для изменения (IME, в любом случае), чем запросы, определенные локально. (Очевидно, есть много других плюсов и минусов, но я ограничиваю себя здесь удобством.)

Что касается технического обслуживания - я полагаю, что возможно, что у вас будет обновление "только для базы данных", состоящее только из таблиц и хранимых процедур, без каких-либо знаний клиентов - в этом случае хранимые процедуры будут лучше переехать. По моему опыту (конечно, с пользовательскими решениями, где есть только несколько приложений, обращающихся к базе данных, поэтому совместимость не является , а большой проблемой), изменения кода почти повсеместны, но изменения базы данных менее распространены - при этом Точка хранения запросов с приложением означает, что вам меньше придется вносить изменения в базу данных при обновлении. Имеет ли что-нибудь из этого смысл? Я еще не пил кофе ...

Answer 3

Я думаю, что лучше использовать хранимые процедуры, потому что их использование дает производительность. В случае, если это возможно.

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

Answer 4

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

Конечно, это также зависит от того, насколько большим будет ваше "обновление". Этот момент будет хорошим, если в бизнес-логике произошли существенные изменения или требуется замена базы данных

Answer 5

В любом случае! Но в каждом конкретном случае,

SQL на уровне кода как константа,

• Значение оценивается во время компиляции, это оптимизирует производительность.
• Это безопасно, его нельзя изменить после компиляции или развертывания кода.
• Некоторые снижают производительность, отправляя весь текст SQL на сервер sql по проводам.
• Некоторый недостаток безопасности, если SQL был создан динамически.

SQL на уровне функций SQL

• Более безопасный, поскольку параметры набран.
• Проще обслуживать по схеме базы данных. например таблица не может быть удалена, если на нее ссылается одна функция.
• Лучшая производительность, просто отправив через имена и параметры функций к серверу SQL.
• Легче применять исправления на уровне функций, поскольку они не компилируются. Люди могут видеть и изменять ваш код, поскольку он отображается в виде простого текста.
• Некоторый недостаток для поддержки версий между приложением и функцией sql.