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

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

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

Как вы думаете, баланс?

Спасибо, Krunal

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

@DannySmurf:

Не отлаживается

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

Он не подлежит контролю источника

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

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

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