сколько работы мы должны сделать в базе данных?

Question

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

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

Но скорее вещи, которые более размыты, включая, но не ограничиваясь этим, «должны ли мы извлечь данные для 4-х столбцов и выполнить прописные буквы / конкатенацию на уровне приложения, или мы должны сделать эти вещи на уровне базы данных и отправить Расчетный результат до уровня приложения?

И если бы вы могли перечислить другие примеры, было бы здорово.

Answer 1

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

Вы можете использовать триггеры и хранимые процедуры / функции в SQL.

Ссылки для MySQL:
http://dev.mysql.com/doc/refman/5.5/en/triggers.html
http://www.mysqltutorial.org/introduction-to-sql-stored-procedures.aspx
http://dev.mysql.com/doc/refman/5.5/en/stored-routines.html

Мои причины для ведения бизнес-логики в триггерах и хранимых процессах

Обратите внимание, что я не говорю об изгибании структуры базы данных к бизнес-логике, я говорю о включении бизнес-логики в триггеры и хранимые процедуры.

1. Он централизует вашу логику , база данных - это центральное место, все должно пройти через это. Если у вас есть несколько точек вставки / обновления / удаления в вашем приложении (или у вас есть несколько приложений), вам нужно будет выполнять проверки несколько раз, если вы делаете это в базе данных, вы должны выполнять проверки только в одном месте.
2. Это упрощает приложение. Например, вы можете просто добавить участника, база данных выяснит, известен ли он уже, и предпринять соответствующее действие.
3. Он скрывает внутренние компоненты вашей базы данных от приложения, если вы выполняете всю свою логику в приложении, вам потребуются сложные знания вашей базы данных в приложении. Если вы используете код базы данных (триггеры / проки), чтобы скрыть это, вам не нужно знать каждую деталь базы данных в вашем приложении.
4. Упрощает перестройку базы данных. Если у вас есть логика в базе данных, вы можете просто изменить раскладку таблицы, заменить старую таблицу таблицей чёрных дыр, установить триггер на нее и позволить триггер выполняет обновление новой таблицы, вашему приложению даже не нужно знать, что база данных изменилась, это позволяет прежним приложениям работать без изменений, в то время как новые приложения могут использовать улучшенный макет базы данных.
5. В SQL некоторые вещи проще
6. Некоторые вещи работают быстрее в SQL
7. Я не люблю использовать (много и / или сложный) код SQL в своем приложении , мне нравится помещать код SQL в хранимую процедуру / функцию и стараться помещать только простые запросы в код моего приложения, таким образом, я могу просто написать код, который объясняет, что я имею в виду в своем приложении, и позволить слою базы данных выполнять тяжелую работу.

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

Answer 2

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

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

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

Если бы я проектировал новое приложение, то обычно выбирал бы схему, которая определяется областью моего приложения (дизайн которой будет в коде). Обычно я позволяю ORM обрабатывать сопоставление между объектами и базой данных. Я бы относился к хранимым процедурам как к исключениям из правила, когда речь заходит о доступе к данным (создание отчетов в sprocs может быть намного проще, чем попытка заставить ORM эффективно создавать сложные выходные данные).

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

Answer 3

По моему мнению, приложение должно использовать данные, а база данных должна предоставлять их, и это должно быть четким разделением проблем.Таким образом, база данных дает записи, отсортированные, упорядоченные и отфильтрованные в соответствии с запрошенными условиями, но это зависит от приложения, чтобы применить некоторую бизнес-логику к этим записям и «преобразовать» их во что-то значимое для пользователя.

Например, в моемВ предыдущей компании мы работали над большим приложением для расчета рабочего времени.Одной из очевидных функциональных возможностей приложений такого типа является отслеживание дней отпуска сотрудников - сколько дней у сотрудника в году, сколько он использовал, сколько осталось и т. Д. По сути, мы могли бы написать несколько триггеров и процедур, которые бы автоматически обновляли эти столбцы.Поэтому, когда у сотрудника были утверждены дни отпуска, количество дней, на которое он подал заявку, берется из его "пула отпусков" и добавляется к "использованным дням отпуска".Довольно простая вещь, но мы решили сделать это явным на уровне приложений и, парень, очень скоро мы были счастливы, что сделали это таким образом.Заявка должна была соответствовать требованиям трудового законодательства, и быстро выяснилось, что не для всех сотрудников дни отпуска рассчитываются одинаково, и иногда день отпуска может быть совсем не таким, но это не имеет значения.Если бы мы поместили эту «простую» операцию в базу данных, нам пришлось бы вносить изменения в нашу базу данных с каждым небольшим изменением логики, связанной с выходными днями, и это привело бы нас к черту в области поддержки клиентов из-за того, что было возможно обновить только приложениебез необходимости обновления базы данных (кроме явных «прорывных» моментов, когда структура базы данных была изменена, конечно).

Answer 4

Как правило, рекомендуется ожидать от базы данных только «Data».Это приложение (я), чтобы применить Business / Domain Logic и понять полученные данные.Настоятельно рекомендуется выполнять следующие действия на уровне приложений:

1) Дата форматирования 2) Применение математических функций, таких как интерполяция / экстраполяция и т. Д. 3) Динамическая сортировка (на основе столбцов)

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