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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@DannySmurf:

Он не поддается отладке

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

Это не подлежит контролю исходного кода

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

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

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

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

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

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

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

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

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