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

Question

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

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

Answer 1

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

Answer 2

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

Удачи!

Answer 3

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

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

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

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

Answer 4

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

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