Куда поместить Ваш код - База данных по сравнению с Приложением? [закрытый]

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

Все остальное должно войти в код.

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

Что-либо, что касается Ссылочной целостности или Непротиворечивости, должно быть в базе данных как абсолютный минимум. Если это находится в Вашем приложении, и кто-то хочет записать приложение против базы данных, они оказываются перед необходимостью копировать Ваш код в своем коде, чтобы гарантировать, что данные остаются последовательными.

PLSQL для Oracle является довольно хорошим языком для доступа к базе данных, и это может также дать повышения производительности. Ваше приложение может также быть намного 'более опрятным', поскольку оно может рассматривать хранимые процедуры базы данных как 'черный квадрат'.

sprocs самостоятельно может также быть настроен и изменен без Вас имеющий необходимость пойти около Вашего скомпилированного приложения, это также полезно, если поставщик Вашего приложения обанкротился или недоступен.

Я не защищаю 'все', должен быть в базе данных, отнюдь нет. Рассматривайте каждый случай отдельно и логически и Вы будете видеть, который имеет больше смысла, помещает его в приложение или помещает его в базу данных.

Я нахожусь в объектно-ориентированном лагере архитекторов. Это - не обязательно преступление для помещения кода в базу данных, пока Вы понимаете протесты, которые соглашаются с этим. Вот некоторые:

1. Это не debuggable
2. Это не подвергается управлению исходным кодом
3. Полномочия на Ваших двух наборах кода будут отличаться
4. Это сделает более трудным отследить, куда ошибка в данных прибыла из того, если Вы получаете доступ к информации в базе данных от обоих мест

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

По моему опыту, типичное приложение ввода данных как некоторый клиент (или xyz) управление в широком масштабе извлечет выгоду из использования уровня ORM, поскольку нет такого количества различных взглядов в данных, и можно уменьшить шаблон код CRUD до минимума.

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

Как упомянуто прежде, это также зависит от множества представлений, которые Вы ожидаете для своих данных. Если существует много различных комбинаций столбцов и таблиц, которые должны быть представлены пользователю, можно также быть более обеспечены просто возвращающие различные наборы результатов, а не отобразить объекты один за другим на другое представление.

В конце концов, база данных способна иметь дело с наборами, тогда как код OO способен иметь дело с единственными объектами.

@DannySmurf:

Это не debuggable

В зависимости от Вашего сервера, да, они debuggable. Это обеспечивает пример для SQL Server 2000. Я предполагаю, что более новые также имеют это. Однако свободный сервер MySQL не имеет этого (насколько я знаю).

Это не подвергается управлению исходным кодом

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

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

@Thomas Owens: (управление исходным кодом ре) Да, но это не управление исходным кодом в том же смысле, что я могу зарегистрироваться в .cs файле (или .cpp файле или безотносительно) и пойти и выбрать любой пересмотр, который я хочу. Чтобы сделать это с кодом базы данных требует потенциально-существенного-количества усилия или получить процедуру от базы данных и передать его куда-нибудь в исходном дереве или сделать резервное копирование базы данных каждый раз, когда незначительное изменение внесено. В любом случае (и независимо от усилия), это не интуитивно; и для многих магазинов, это не достаточно хорошее решение также. Существует также потенциал здесь для разработчиков, которые не могут быть столь же прилежными в этом как другие, чтобы забыть получать и регистрироваться в пересмотре. Технически возможно поместить ЧТО-ЛИБО в управление исходным кодом; разъединение здесь - то, с чем я не согласился бы.

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

Ну, этот является трудным. Как программист, Вы захотите избежать TSQL и таких "Языков базы данных" как можно больше, потому что они являются ужасающими, трудными отладить, не расширяемый и нет ничего, что можно сделать с ними, что Вы не сможете сделать использующий код на своем приложении.

Единственные причины я вижу запись хранимых процедур:

1. Ваша база данных не является большой (думайте, как SQL Server не реализует ПРЕДЕЛ, и необходимо работать вокруг того использования процедуры.
2. Вы хотите смочь изменить поведение путем изменения кода во всего одном месте, не повторно развертывая клиентские приложения.
3. Клиентские машины имеют большие ограничения питания вычисления (думайте маленькие встроенные устройства).

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

Ну, если Вы заботитесь о непротиворечивости Ваших данных, существуют причины реализовать код в базе данных. Поскольку другие сказали, поместив код (и/или RI/ограничения) в действиях базы данных для осуществления бизнес-логики, близко к самим данным. И, это обеспечивает общий, инкапсулированный интерфейс, так, чтобы Ваш новый разработчик случайно не создавал записи висячей строки или непоследовательные данные.