Чи порушуються збережені процедури трирівневим поділом?

Деякі мої колеги сказали мені, що використання бізнес-логіки при збережених процедурах в базі даних порушує трирівневу архітектуру поділу, оскільки база даних належить до рівня даних, тоді як збережені процедури - це бізнес-логіка.

Я думаю, що світ був би дуже похмурим місцем без збережених процедур.

Вони дійсно порушують трирівневу поділ?

Ваші колеги поєднують архітектуру з реалізацією.

Ідея багатоярусного додатка полягає просто в тому, що він розбивається на частини, які включають певні види обробки (зберігання, ділова логіка, презентація) та спілкуються між собою за допомогою чітко визначених інтерфейсів. Так само, як можна успішно робити речі, що нагадують об'єктно-орієнтоване програмування на не об’єктно-орієнтованих мовах, так можна зробити те ж саме з декількома ярусами в одному середовищі, наприклад сервер бази даних. Те, що робить один із тих, хто успішно має спільне, - це потреба в турботі, дисципліні та розумінні компромісів, що стосуються.

Давайте розглянемо трирівневу програму, де два з ярусів реалізовані в базі даних:

• Рівень даних: Складається з таблиць бази даних , доступ з допомогою чотирьох стандартних операцій таблиці ( INSERT, UPDATE, DELETEі SELECT).
• Логічний рівень: складається із збережених процедур, які реалізують лише бізнес-логіку та отримують доступ до рівня даних, використовуючи лише описані вище методи.
• Рівень презентації: складається з запущеного коду веб-сервера, який здійснює доступ до логічного рівня, здійснюючи лише збережені виклики процедури.

Це цілком прийнятна модель, але вона має деякі компроміси. Бізнес-логіка реалізована таким чином, що забезпечує швидкий, простий доступ до рівня даних і може дозволяти робити те, що доведеться робити "важким шляхом" за допомогою логічного рівня за межами бази даних. Що ви відмовляєтеся - це можливість легко перейти будь-який рівень на якийсь інший біт технології та безтурботне впровадження (тобто, ви повинні бути особливо обережними, щоб яруси не використовували засоби, доступні в базі даних, але поза їх визначеними інтерфейсами) .

Незалежно від того, чи є така річ і чи не вигідні в цій ситуації компроміси - це те, що ви та ваші колеги повинні визначити, використовуючи ваше судження.

Збережені процедури є досить потужними, щоб дозволити кодувати порушення трирівневого поділу шляхом введення ділової логіки в рівень RDBMS. Однак це ваше рішення, а не притаманний ваді збережених процедур. Ви можете обмежити свої SP на обслуговування потреб вашого рівня даних, зберігаючи свою логіку програми на рівні програми вашої архітектури.

Є рідкісний, але важливий виняток із правила розділення, коли вам потрібні збережені процедури (конкретно, група тригерів), щоб містити бізнес-логіку. Це трапляється, коли вашій програмі потрібно створити безліч оперативних агрегацій даних, які торкаються мільйонів рядків. У подібних випадках можуть бути налаштовані тригери для підтримки попередньо зібраних даних для використання бізнес-рівня. Це слід робити лише в тих випадках, коли без попередньої агрегації ваша заявка була б неприпустимо повільною.

Порада Етвуда з 2004 року діє і сьогодні, лише зараз ми маємо перевагу ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Збережені процедури повинні вважатися мовою складання бази даних: для використання лише в найважливіших критичних ситуаціях. Існує маса способів розробити надійний, високоефективний рівень доступу до даних, не вдаючись до збережених процедур; Ви отримаєте багато переваг, якщо будете дотримуватися параметризованого SQL та єдиного узгодженого середовища розробки.

Короткий підсумок: Це дійсно залежить від вашого використання збережених процедур та бізнес-вимог.

Існує ряд проектів, які використовують трирівневу архітектуру, і залежно від характеру вимог бізнесу, можливо, буде потрібно перенести деякі операції на рівень даних.

Якщо говорити про термінологію, то загалом ці рівні описані як:

• Рівень презентації або рівень обслуговування користувачів - надає користувачеві доступ до програми.
• Середній рівень або рівень бізнес-послуг - складається з правил бізнесу та даних.
• Рівень даних або рівень послуг даних - взаємодіє з постійними даними, які зазвичай зберігаються в базі даних або в постійному сховищі.

Зазвичай для даної архітектури середній рівень або рівень бізнес-послуг складається з правил бізнесу та даних. Однак іноді має велику різницю зміщення операцій з великими базовими операціями та / або правилами даних, що виконуються в рівні даних - через набір збережених процедур.

Перевагами трирівневих конструкцій є:

Під час життєвого циклу програми трирівневий підхід забезпечує такі переваги, як повторне використання, гнучкість, керованість, ремонтопридатність та масштабованість. Ви можете надавати спільний доступ до компонентів і служб, які ви створюєте, та використовувати їх, а також за необхідності поширювати їх по мережі комп’ютерів. Ви можете розділити великі та складні проекти на більш прості проекти та призначити їх різним програмістам або командам програмування. Ви також можете розгортати компоненти та сервіси на сервері, щоб не відставати від змін, і ви можете їх повторно розміщувати у міру збільшення бази користувачів, даних та обсягу транзакцій програми.

Таким чином, це дійсно конкретний підхід, який сам по собі має компроміси. Однак, керівні принципи дизайну Microsoft для трирівневої архітектурної моделі рекомендують підтримувати вашу бізнес-логіку середнього рівня.

Рівень фактично означає різну машину, шар означає різне логічне розділення. Зі збереженими процедурами у вас є рівень даних і (принаймні частина) рівня логіки бізнесу в одному рівні. Введення бізнес-логіки в збережені процедури порушує 3-стомлену архітектуру, але сумнівно, чи вона порушує 3-шарову архітектуру; одна впевнена річ - це те, що це не є гарним прикладом розділення проблем.

Шар - це логічний механізм структурування елементів, що складають ваше програмне рішення; рівень - це фізичний механізм структурування системної інфраструктури. ( Довідка )

На мою думку, у базі даних є дві основні проблеми з побудовою бізнес-логіки:

1. Код і бібліотеки: ви знайдете менше програмістів, які зможуть програмувати в SQL, PL / SQL, TSQL і т. Д., Ніж у C #, Java тощо. Мови програмування також мають перевагу у великих IDE, чудових бібліотеках та каркасах.

2. Горизонтальна масштабованість: єдиний спосіб масштабування вашої системи полягає в зміні фізичного сервера, на якому база даних є більш потужним, який є досить дорогим (сервер із 64 ГБ оперативної пам’яті); реляційні бази даних масштабуються по горизонталі дуже погано, і навіть за великих витрат. Хоча, використовуючи бізнес-логіку на побудованому OO сервері, ви можете досить масштабувати горизонтально, розміщуючи сервер на багатьох вузлах (на Java це підтримують багато серверів програм).

Деякі дискусії в нашому офісі ми проводили кілька разів тому, я виступав за розробку бази даних, і я переглядав це

1. Якщо ви використовуєте базу даних Oracle, ви повинні максимально використовувати PL / SQL, тому що, напевно, компанії, які інвестують, буде дотримуватися оракул принаймні навіть 10 років відтепер. Якщо ви вчора в додатках використовували Oracle Forms, сьогодні .net веб-форми, потім MVC, то завтра ви будете використовувати angularjs і просто потрібні спокійні apis. Якщо у вашій базі даних є максимальна логіка, ви можете легко перейти до нових передових технологій.
2. Розробка бази даних дуже швидка і дуже ефективна. Просто, щоб дати вам перспективу. У нашому проекті було 7 розробників додатків та один розробник баз даних, і 80% логіки було в базі даних.
3. Якщо ви використовуєте Oracle, ви можете використовувати утиліти для прямого перетворення процедур вашої бази даних у Res full Api.

Найсильніший аргумент, який розробники додатків стверджують, що бізнес-логіка повинна бути незалежною від бази даних, щоб ви могли легко змінити базу даних. Я думаю, якщо компанія використовує Oracle, чому вони перейдуть на іншу технологію, а не більше шансів отримати застарілу логіку програми. Питання в основному не вистачає нового таланту ресурсу бази даних, в основному хлопці почнуть прості веб-сайти, де вони використовують mysql або sqlserver. Потім ці хлопці стають старшими ведучими та емоційно прив’язуються до шару програми :) вони навіть не хочуть розуміти чи дискутувати.