Где должны храниться запросы к базе данных?

Question

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

В первой ситуации изменение ваших запросов не повлияет на других людей (либо на другой код, либо на людей, генерирующих отчеты и т. Д.). Во втором случае запросы многократно используются многими и существуют только в одном месте, но если кто-то их сломает, они разбиты для всех.

Answer 1

Раньше я был большим в сохраненном решении proc, но изменил мою настройку в прошлом году, поскольку базы данных стали быстрее, и ORM вошли в основной поток. Конечно, есть место для хранения procs. Но когда дело доходит до простого CRUD-кода: одна вкладка liner/update/select/delete, использование ORM для обработки это самое элегантное решение, на мой взгляд, но я уверен, что многие будут спорить по-другому. ORM построит соединение SQL и DB с вашим кодом и сделает логику персистентности более гибко интегрированной с вашим приложением.

Answer 2

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

Удачи вам!

Answer 3

Это зависит от ситуации. Есть очень сильные аргументы для и против любого варианта. Лично мне действительно не нравится, когда бизнес-логика разделяется между базой данных (в хранимых процедурах) и кодом, поэтому я обычно хочу, чтобы все запросы в коде были максимально возможными.

В мире Microsoft существуют такие вещи, как Reporting Services, которые могут извлекать данные из классов/объектов вместо (и в дополнение) к базе данных/хранимым процедурам. Кроме того, есть такие вещи, как Linq, которые дают вам более строго типизированные запросы в коде. Существуют также сильные, зрелые ORM, такие как NHibernate, которые позволяют писать практически все типы запросов из кода.

Тем не менее, все еще есть моменты, когда вы делаете «набор строк» ​​с вашими запросами, которые работают намного лучше в хранимой процедуре, чем они работают из кода.

В большинстве ситуаций оба варианта оба варианта работают нормально.

Answer 4

С моей точки зрения, я думаю, что сохраненные проки - это путь. Во-первых, их проще обслуживать, так как быстрое переключение на один означает просто запустить сценарий, не перекомпилируя приложение. Во-вторых, они намного лучше для безопасности. Вы можете устанавливать разрешения на уровне sp, а не непосредственно на таблицах и представлениях. Это помогает предотвратить мошенничество, потому что пользователи не могут ничего сделать непосредственно в базе данных, которая не указана в хранимой процедуре. Они легче настраиваются. Когда вы используете хранимые procs, вы можете использовать метаданные зависимости базы данных, чтобы помочь определить влияние изменений базы данных на базу кода. Во многих системах не все операции доступа к данным или даже CRUD будут выполняться через приложение, поскольку код, как мне кажется, является контрпродуктивным. Если весь доступ к данным находится в одном месте (идея, которую я поддерживаю), она должна быть в базе данных, где она доступна для всех приложений или процессов, которые могут потребоваться для ее использования.

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