Если есть какие-то администраторы баз данных, я делаю довольно большой набор программного обеспечения, и в настоящее время одной из самых больших проблем является то, где поставить бизнес-логику. Хотя Хранимые процедуры будут легче исправлять “на лету”, требования к обработке, вероятно, замедлят работу базы данных. Я также не хочу иметь всю бизнес-логику, обрабатываемую приложением, потому что я хочу, чтобы она была “самоподдерживающейся сущностью”, которая не требует, чтобы пользовательский интерфейс работал.
Моя идея: создать сервис, который будет запускаться на центральном сервере где-нибудь, и подключить к нему клиентов. Служба будет поддерживать всю бизнес-логику и служить интерфейсом для всех операций с базой данных.
Я согласен с тем, что мне также не хватает некоторых ключевых концепций и вам нужно прочитать какую-то литературу.
Лучший ответ:
Что вы подразумеваете под “бизнес-логикой”?
Я видел случаи, когда в клиентском коде выполнялись агрегации и другие операции с множеством, а также ужасные действия RBAR в SQL, которые должны быть где-то еще.
Архитектура ПО, MVC и бизнес-логика. Критика Django
SQL – это один из инструментов, который имеет место: если вы работаете с большими наборами данных, JOINs, агрегациями и т.д., то SQL – это место для этого. Все остальное – рабское подчинение идеалу SOA.
Мой подход заключается в том, чтобы рассмотреть, что делает хранимый proc или SQL: является ли он частью среднего уровня, чтобы избежать операций на основе набора в процедурный код, или он ниже, чем чистая целостность данных/постоянство?
Если ваша бизнес-логика установлена на 100%, тогда вам не нужен средний уровень (редактирование: клиентский код), если только он не очень тонкий.
Я бы предположил, что вы внимательно следите за тем, что вы думаете о бизнес-логике и каковы ограничения ссылочной целостности.
Удостоверьтесь, что все ограничения, которые содержат существенные данные, находятся на уровне базы данных. то есть, если вам нужно каскадировать некоторые удаления или вставки – и когда вам нужно проверить некоторые базовые значения данных, чтобы все имело смысл… все они должны быть в базе данных.
Затем определите, подходит ли клиент, сервер среднего уровня или база данных для любой дополнительной бизнес-логики.
На протяжении многих лет я видел, как клиентские приложения приходят и уходят, но база данных все еще существует.
Итак, в настоящее время я использую хранимые процедуры для большей части бизнес-логики. Три больших преимущества:
- Исправление ошибок исправления принимает мгновенное, без простоя
- Мультипользователь по умолчанию
- Значительно меньше сантехники (без доступа к данным)
Наличие всей бизнес-логики на стороне сервера в порядке.
Не иметь его на стороне сервера тоже хорошо.
На самом деле это зависит от вас.
Если хранимая процедура имеет тенденцию выглядеть не sql-ish, вы можете сделать хранимую процедуру CLR.
Я бы рекомендовал традиционный подход n-уровня, где у вас есть хотя бы уровень пользовательского интерфейса, бизнес-уровень (например, сборка С# или Java-эквивалент) и доступ к данным. См.: http://en.wikipedia.org/wiki/Multitier_architecture.
#8 Бизнес логика или детали реализации? — Vue.js: концепции
Я работал в компании, где вся бизнес-логика была в procs, а затраты на поддержку намного выше, чем они были, это ограничивало нас конкретной версией SQL-сервера, она не была масштабируемой и т.д. В Короче говоря, если ваше приложение не является простым броском, я бы не поместил в базу данных бизнес-логику.
Источник: techarks.ru
Русские Блоги
[Рабочие вопросы] Немного сложная реализация SQL: как втиснуть бизнес -логику в оператор SQL?
Сцены
В последнее время развитие Pan -Micro Company столкнулась с неприятной проблемой. Существует спрос на это: основной список компаний, выставляющих счетов, которая рассчитывает оставшуюся квоту в режиме реального времени. Согласно общей логике MVC, это очень просто. Во -первых, возьмите все основные списки компании, а затем цикл, чтобы пройти сумму в соответствии с различными условиями, которые будут назначены на переднюю часть.
Но сторона Панчен не очень хороша (разработанные братья должны понимать . ), потому что передняя часть была глубоко инкапсулирована, и спрос не может быть достигнут, вызывая внешний интерфейс и проходящие параметры. Остается только один путь, который остается,Вся бизнес -логика реализована через SQL, Pan -Micro Front End вызывает SQL и прошел параметр и возвращает в реальном расчете.
Спрос на расщепление
Вначале я чувствовал, что это не может быть достигнуто. Как может быть бизнес -логика в SQL? (10 000 травяных грязевых лошадей в вашем сердце . )
Но после успокоения, подумав об этом, это действительно возможно. В конце концов, есть в SQLЕсли утверждение,Контроль времениbetweenВы также можете сделать это, черезleft joinВозьмите данные из остальных таблиц SУм плюс или вычтитеДавайте снова получим эту логикуgroupИспользуйте его по каждому предмету.
Логика выглядит очень грязно, но на самом деле каждый шаг упрощен, мышление все еще очень ясное.
выполнить
1. Во -первых, возьмите данные основной таблицы компании:
SELECT a.id, a.hm, a.gsmc, a.skzhkh, a.mmoney FROM uf_mainmanagement
2. Начните влево соединить каждую необходимость добавить рассчитанные таблицы
SELECT a.id, a.hm, a.gsmc, a.skzhkh, a.mmoney FROM uf_mainmanagement a LEFT JOIN uf_billingrecord b ON a.id = b.oursubject LEFT JOIN uf_invoice_record c ON a.id = c.gszt LEFT JOIN uf_oainvoice_return d ON a.id = d.kpzt .
3. начал рассчитывать требуемые данные каждой таблицы в зависимости от времени и уточнения квот
SELECT a.id,a.remainamount,a.oursubject from uf_billingrecord a left join uf_mainmanagement b on a.oursubject = b.id where invoicedate BETWEEN IF(b.type=1,date_sub(‘2020-09-24’,interval 1 year),date(concat(year(‘2020-09-24′),’-‘,elt(quarter(‘2020-09-24′),1,4,7,10),’-‘,1))) and IF(b.type=1,’2020-09-24’,LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM ‘2020-09-24’),1) + interval QUARTER(‘2020-09-24’)*3-1 month))
Через левый субъект соединения, были получены тип квоты и время выставления счетов основного тела данных. В зависимости от типа квоты метод расчета времени был другим, например:Тип квоты — годФормула расчета:
Оставшаяся квота = общая квота -квота выставления счетов (время на сегодняшний день доведено до сегодняшнего года) -квота на назначение (без ограничения по времени)
а такжеТип квоты ежеквартальноФормула расчета:
Оставшаяся квота = общая квота -квота выставления счетов (первый день до последнего дня текущего квартала до последнего дня) -квота назначения (первый день до последнего дня квартала до последнего дня текущего времени )
Приведенные выше требования могут быть достигнуты через MySQL, если утверждение:
IF(b.type=1,Формула расчета времени1,Формула расчета времени2)
Отдельная таблица сделана, и следующий шаг прост:
Просто нужно поместить ту же логику в каждое левое соединение
SELECT a.id, a.hm, a.gsmc, a.skzhkh, a.mmoney FROM uf_mainmanagement a LEFT JOIN (SELECT a.id,a.remainamount,a.oursubject FROM uf_billingrecord a LEFT JOIN uf_mainmanagement b ON a.oursubject = b.id WHERE invoicedate BETWEEN IF(b.type=1,date_sub(‘2020-09-24’,interval 1 year),date( concat(year(‘2020-09-24′),’-‘,elt(quarter(‘2020-09-24′),1,4,7,10),’-‘,1))) AND IF(b.type=1,’2020-09-24’, interval QUARTER(‘2020-09-24’)*3-1 month))) b ON a.id = b.oursubject LEFT JOIN () .
4. Удалите данные, которые были рассчитаны на основе времени, в формуле добавляется сумма:
Данные NULL установлены 0, в противном случае сообщается об ошибке
Наконец добавьте индекс
SELECT a.id, a.hm, a.gsmc, a.skzhkh, a.mmoney, (case a.type when ‘1’ then ‘год’ when ‘2’ then ‘Четверть’ ELSE ‘Unlimited’ end ) type, a.mmoney — sum( IFNULL( f.bckpje, 0 ) ) — sum( IFNULL( b.remainamount, 0 ) ) — sum( IFNULL( c.kpje, 0 ) ) + sum( IFNULL( d.tpje, 0 ) ) + sum( IFNULL( e.kpje, 0 ) ) AS remainamount, sum( IFNULL( f.bckpje, 0 ) ) + sum( IFNULL( b.remainamount, 0 ) ) + sum( IFNULL( c.kpje, 0 ) ) as usedamount FROM
Подвести итог
Бизнес -логика SQL Total Stucking на самом деле нежелательна. Один нелегко поддерживать, а другая заключается в том, что читаемость слишком плохая. Сущность.
Но это требование действительно позволяет мне лучше понять утверждение SQL, а также позволяет мне испытать удобство модели разработки пружины .
Источник: russianblogs.com
Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры
В данных системах хранение, выборка и поддержание непротиворечивости данных возлагается на сервер БД , а вся бизнес-логика и логика представления исполняются на клиентских машинах. Так как все операции по манипулированию данными осуществляются только через сервер , производительность и сохранность данных зависит только от сервера БД . Серверы БД изначально рассчитаны на многопользовательский режим работы, имеют эффективные алгоритмы кеширования данных. Современные серверы имеют хорошую масштабируемость .
Клиентская часть обменивается данными с сервером посредством SQL запросов. Обработка информации в клиент -серверных системах ведется на уровне множества кортежей .
Процесс разработки разделяется на создание БД и написание клиентской части с бизнес-логикой.
Достоинства
- Высокая производительность , стабильность и надежность при многопользовательской работе.
- Легко организуется защита данных ( шифрование сетевого трафика SSH , SSL )
- Универсальность языка определения и манипулирования данными
- Более высокая цена СУБД . (сервер БД продается отдельно).
- Достаточно высокие требования к квалификации разработчиков
- Навыки администрирования сервера БД
- Повышенные требования к пропускной способности сети
- Повышенные требования к клиентским местам (на них выполняется слой бизнес- логики)
При количестве пользователей от 2 до ~50 она является хорошим вариантом. С ростом числа пользователей начинает сказываться недостаточная пропускная способность сети .
Клиент-сервер с бизнес-логикой на сервере
Используется возможность современных серверов БД исполнять хранимые SQL процедуры на сервере, куда и переносится максимально возможная часть бизнес-логики. Требования к серверу БД возрастают, однако резко понижаются требования к клиентским машинам (за счет выноса с них бизнес-логики) и к пропускной способности сети (клиенту передаются только данные, необходимые пользователю).
Достоинства
- Пониженные, по сравнению с предыдущим классом систем, требования к пропускной способности сети и клиентским местам.
- Более простой процесс создания бизнес-логики.
- Повышенные требования к серверу БД .(каждый сеанс «съедает» память из расчета предельной загрузки)
- Невысокая переносимость (мобильность) системы на другие серверы БД .
По сравнению с предыдущими классами, позволяет держать большую нагрузку.
N-уровневая архитектура
Основными элементами являются сервера БД , сервер ( кластер ) приложений и клиентская часть. Главная идея n-уровневой архитектуры заключается в максимальном упрощении клиента (тонкий клиент ) , выносе всей бизнес-логики с клиента и сервера БД .
Тонкий клиент представляет собой некоторый терминал типа HTML — browser или эмуляторы X- терминала
Вся бизнес- логика оформляется в виде набора приложений, запускаемых на сервере приложений под управлением ОС типа UNIX .
Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.
Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети .
Достоинства
- Повышенная защищенность.
- Высокая производительность .
- Легкость развития и модификации.
- Легкость администрирования .
- Возможность создания системы с массовым параллелизмом (серверов БД может быть несколько, а сервером приложений могут служить несколько соединенных в кластер компьютеров ).
- Высокая сложность.
- Высокая цена решения.
- В некоторых случаях уступает по производительности клиент -серверным системам с бизнес-логикой на сервере.
Единственная альтернатива для создания ИС для очень большого количества пользователей.
Практические занятия
Постановка задачи. Проектирование данных на концептуальном и логическом уровнях. Нормализация отношений.
Подготовка SQL скриптов генерации схемы отношений БД в ERwin. Разработка скрипта для ввода тестовой информации.
Архитектура MS SQL Server 2005. Настройка и использование основных компонент среды. Создание учебной базы данных.
Работа с СУБД MS SQL Server 2005, ORACLE 10g. Примеры соединений с БД, технологии разработки клиенского приложения
Использование технологии Java Database Connectivity (JDBC) для работы с базами данных
Примеры к презентации
Листинг P.1. Выполнение запроса: QuerySample.java
Листинг P.2. Выполнение хранимой процедуры: StoredProcedureSample.java
Источник: intuit.ru
