Бизнес-логика в базе данных по сравнению с кодом?

Оригинал доступен по ссылке ниже: Если вы рассматриваете архитектуру , не забудьте взвесить эту дополнительную проблему в сравнении с преимуществами пользователя, которые вы получите. В традиционном веб-приложении, независимо от платформы вашего веб-сервера, среды и т. Если вы хотите добавить редактор например, для вашего приложения, вам нужно добавить несколько таблиц базы данных уровень данных и некоторый код, который создает и обрабатывает формы, когда пользователи вносят изменения уровень веб-сервера. В вы, очевидно, все еще будете иметь уровень данных, у вас будет уровень веб-сервера, который предоставляет данные через веб-службы или , и, наконец, у вас будет уровень браузера с кодом на основе , который представляет данные для пользователей и обрабатывает обновления. Рассмотрим код для простого дисплея только для чтения, который показывает клиента и некоторые заказы. ; Благодаря архитектуре вы, по сути, должны иметь дело с заказчиком и заказами дважды. Дело не в том, что вам приходится выполнять любые механические задачи дважды: В традиционном веб-приложении вы можете перейти прямо из данных в конечное представление с помощью одного блока кода на веб-сервере.

Сколько бизнес-логики должна реализовывать база данных?

Проектирование и рефакторинг В этой статье я попробую сам разобраться в себе и в своих аргументах. Для начала попробую оппонировать автору статьи, перевод которой нашел на хабре Где наша бизнес-логика, сынок? Её писал такой же идеалист, которым я был еще лет 10 назад. Поэтому по сути в этой статье я буду спорить сам с собой.

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

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

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

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

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

S>Какие аргументы есть _против_ размещения бизнес логики на к базе данных, а работает только с объектами бизнес-логики.

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

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

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

Сложная бизнес-логика. Как всё учесть?

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

Вот примерный список бизнес-данных взятых из предметной области: создаваемых аналитиком или архитектором базы данных.

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

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

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

Может ли эта бизнес-логика быть принудительно привязана к условной базе данных?

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

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

Написано : Если делать с расчет на расширяемость, то в объекте в котором собрано все состояние игрока должно быть поле класса , который отвечает за состояние прогресса науки. У него должен быть метод типа , который принимает возможно, строковое или технологии и возвращает булево значение доступна или нет. Только сам корабль"знает" технологию ее , необходимую для его создания, поэтому проверка идет в конструкторе конкретного класса корабля. Можно унаследовать все корабли от базового класса и реализовать проверку технологии в определенном поле в его конструкторе, тогда в производных классах останется только менять значение этого поля, но это оставляет возможность создания каких-то особенных кораблей, которые будут проверять технологии каким-то нестандартным способом, если переопределять не поле а сам метод проверки.

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

Бизнес-логика в

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

Если выделять каждый уровень по его функциональности, то получится следующий вывод:

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

Для чего этот запрос? В обычном приложении это не нужно. Это либо нужно для"отчетов", либо для"аналитки". В первом случае лучше использовать построитель отчетов для меня . Во втором случае использовать для меня Я реализовал его с помощью процедурного языка то есть сделал несколько элементарных селектов, а все остальные операции делала уже другая программа и в виде запроса и когда сравнил скорость выполнения то всё стало на свои места. Оптимизатор запросов в субд решает!

Организация бизнес логики со сложной схемой данных. Тимофей Кукушкин.