Где разместить свой код - База данных или Приложение?
Я занимаюсь разработкой веб / настольных приложений около 6 лет. В течение моей карьеры я сталкивался с приложением, которое было в значительной степени записано в базу данных с использованием хранимых процедур, тогда как во многих приложениях было только несколько базовых хранимых процедур (для чтения, вставки, редактирования и удаления записей сущностей) для каждой сущности.,
Я видел, как люди утверждают, что, если вы заплатили за корпоративную базу данных, широко используйте ее возможности. В то время как многие "объектно-ориентированные архитекторы" говорили мне, что абсолютно бессмысленно помещать в базу данных нечто большее, чем необходимо, и вы должны иметь возможность управлять приложением, используя методы этих классов?
Как вы думаете, где баланс?
Спасибо, Крунал
10 ответов
Я думаю, что это бизнес-логика против логики данных. Если есть логика, которая обеспечивает согласованность ваших данных, поместите их в хранимую процедуру. То же самое для удобных функций для поиска / обновления данных.
Все остальное должно идти в коде.
Мой друг разрабатывает множество хранимых процедур для алгоритмов анализа данных в биоинформатике. Я думаю, что его подход довольно интересный, но не правильный путь в долгосрочной перспективе. Моими основными возражениями являются ремонтопригодность и отсутствие адаптивности.
Я в лагере объектно-ориентированных архитекторов. Ввод кода в базу данных не обязательно является преступлением, если вы понимаете предостережения, которые сопровождают это. Вот некоторые:
- Это не отлаживается
- Это не подлежит контролю источника
- Разрешения на ваши два набора кода будут отличаться
- Будет сложнее отслеживать, откуда произошла ошибка в данных, если вы обращаетесь к информации в базе данных из обоих мест.
Все, что относится к ссылочной целостности или согласованности, должно быть в базе данных как минимум. Если оно находится в вашем приложении, и кто-то хочет написать приложение для базы данных, ему придется дублировать ваш код в своем коде, чтобы обеспечить согласованность данных.
PLSQL для Oracle является довольно хорошим языком для доступа к базе данных, а также может повысить производительность. Ваше приложение также может быть более "аккуратным", поскольку оно может рассматривать хранимые процедуры базы данных как "черный ящик".
Сами sprocs также могут быть настроены и изменены без необходимости прибегать к скомпилированному приложению, это также полезно, если поставщик вашего приложения обанкротился или недоступен.
Я не сторонник того, что "все" должно быть в базе данных, это далеко не так. Рассматривайте каждый случай отдельно и логически, и вы увидите, что имеет больше смысла, поместите его в приложение или поместите в базу данных.
Я прихожу почти с одного и того же происхождения и слышал те же аргументы. Я понимаю, что есть очень веские причины для размещения логики в базе данных. Однако это зависит от типа приложения и способа обработки данных, какой подход вам следует выбрать.
По моему опыту, типичное приложение для ввода данных, например, управление клиентом (или xyz), получит огромную выгоду от использования уровня ORM, так как данных не так много, и вы можете сократить стандартный CRUD-код до минимума.
С другой стороны, предположим, что у вас есть приложение с большим количеством параллельных вычислений и вычислений, которые охватывают множество таблиц, и которое имеет детальную концепцию безопасности на уровне столбцов с блокировками и т. Д., Вам, вероятно, лучше делать такие вещи, как это непосредственно в базе данных.
Как упоминалось ранее, это также зависит от разнообразия представлений, которые вы ожидаете от своих данных. Если существует много различных комбинаций столбцов и таблиц, которые необходимо представить пользователю, вам также может быть лучше просто передать различные наборы результатов, а не отображать ваши объекты одно за другим в другое представление.
В конце концов, база данных хороша для работы с множествами, тогда как ОО-код хорошо справляется с отдельными объектами.
Читая эти ответы, я смущен отсутствием понимания программирования баз данных. Я разработчик Oracle Pl/sql, мы контролируем исходный код для каждого кода, который входит в базу данных. Многие из IDE предоставляют надстройки для большинства основных продуктов контроля версий. От ClearCase до SourceSafe. Инструменты Oracle, которые мы используем, позволяют нам отлаживать код, поэтому отладка не является проблемой. Вопрос больше в логике и доступности.
Как менеджер поддержки около 5000 пользователей, чем меньше мест, где мне приходится искать логику, тем лучше. Если я хочу убедиться, что логика применяется ко ВСЕМ приложениям, использующим данные, даже к бизнес-логике, я помещаю ее в БД. Если логика отличается в зависимости от приложения, они могут нести ответственность за это.
Мое личное предпочтение - постараться сохранить как можно больше логики и конфигурации в базе данных. В настоящее время я сильно зависим от Spring и Hibernate, так что это значительно облегчает работу. Я склонен использовать именованные запросы Hibernate вместо хранимых процедур и статической информации о конфигурации в XML-файлах контекста приложения Spring. Все, что нужно добавить в базу данных, должно быть загружено с использованием сценария, и я сохраняю эти сценарии в управлении версиями.
@DannySmurf:
Это не отлаживается
В зависимости от вашего сервера, они могут быть отлажены. Это обеспечивает пример для SQL Server 2000. Я предполагаю, что у более новых также есть это. Тем не менее, бесплатный сервер MySQL не имеет этого (насколько я знаю).
Это не подлежит контролю источника
Да, это. Вид. Резервные копии базы данных должны включать хранимые процедуры. Эти файлы резервных копий могут быть или не быть в вашем хранилище контроля версий. Но в любом случае у вас есть резервные копии ваших хранимых процедур.
@ Томас Оуэнс: (контроль над исходным кодом) Да, но это не контроль исходного кода в том смысле, в котором я могу проверить файл.cs (или файл.cpp или любой другой) и пойти и выбрать любую ревизию, которую я хочу. Для этого с кодом базы данных требуется потенциально значительное количество усилий, чтобы либо извлечь процедуру из базы данных и перенести ее в какое-либо место в исходном дереве, либо сделать резервную копию базы данных каждый раз, когда вносятся незначительные изменения. В любом случае (и независимо от количества усилий) это не интуитивно понятно; и для многих магазинов это тоже не достаточно хорошее решение. Здесь также есть потенциал для разработчиков, которые могут быть не настолько прилежны в этом, как другие, забыть найти и проверить ревизию. Технически возможно поставить НИЧЕГО в систему контроля версий; разъединение здесь - то, с чем я бы взял проблему.
(отлаживаемо) Достаточно справедливо, хотя это не обеспечивает большой интеграции с остальной частью приложения (где могла бы жить большая часть кода). Это может или не может быть важным.
Что ж, если вы заботитесь о согласованности ваших данных, есть причины для внедрения кода в базу данных. Как уже говорили другие, размещение кода (и / или RI/ ограничений) внутри базы данных действует для обеспечения бизнес-логики, близкой к самим данным. Кроме того, он обеспечивает общий инкапсулированный интерфейс, так что ваш новый разработчик не может случайно создать потерянные записи или противоречивые данные.
Ну, это сложно. Как программист, вам нужно как можно больше избегать TSQL и таких "языков баз данных", потому что они ужасны, сложны в отладке, не расширяемы, и вы ничего не можете с ними сделать, чего не сможете сделать используя код в вашем приложении.
Единственные причины, которые я вижу для написания хранимых процедур:
- Ваша база данных невелика (подумайте, как SQL Server не реализует LIMIT, и вам нужно обойти это, используя процедуру.
- Вы хотите иметь возможность изменять поведение, изменяя код в одном месте, без повторного развертывания клиентских приложений.
- Клиентские машины имеют большие ограничения вычислительной мощности (представьте себе небольшие встроенные устройства).
Однако для большинства приложений вы должны стараться хранить свой код в приложении, где вы можете отлаживать его, держать его под контролем версий и исправлять его, используя все инструменты, предоставленные вам вашим языком.