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

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

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

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

Все остальное должно быть в коде.

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

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

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

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

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

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

Что ж, это сложно. Как программист, вы захотите по возможности избегать TSQL и подобных «языков баз данных», потому что они ужасны, их сложно отлаживать, не расширяемо, и вы не можете с ними ничего сделать, чего не смогли бы сделать. используя код в вашем приложении.

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

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

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

@DannySmurf:

Это не отлаживается

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

Это не подлежит контролю версий

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

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

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

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

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

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

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

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

Что ж, если вы заботитесь о согласованности ваших данных, есть причины для реализации кода в базе данных. Как уже говорили другие, размещение кода (и / или ограничений RI /) внутри базы данных обеспечивает выполнение бизнес-логики рядом с самими данными. Кроме того, он предоставляет общий инкапсулированный интерфейс, чтобы ваш новый разработчик случайно не создал ненужные записи или несогласованные данные.

Читая эти ответы, меня смущает непонимание программирования баз данных. Я разработчик Oracle Pl / sql, мы контролируем исходный код каждого бита кода, который попадает в базу данных. Многие из IDE предоставляют надстройки для большинства основных продуктов управления версиями. От ClearCase к SourceSafe. Инструменты Oracle, которые мы используем, позволяют нам отлаживать код, поэтому отладка не является проблемой. Вопрос скорее в логике и доступности.

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