Які аргументи проти або для введення логіки програми в рівень бази даних? [зачинено]


45

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

Особисто я вважаю за краще тримати якомога більше в шарі додатків, щоб полегшити налагодження і зберігати обов'язки шарів окремо.

Які ваші думки з цього приводу, а що потрібно або не слід добре реалізовувати у шарі бази даних?

Редагувати Це питання також висвітлюється на dba.se з точки зору DBA. Оскільки програмісти.se та dba.se мають різні аудиторії та упередження, майбутні читачі, можливо, захочуть переглянути обидва набори відповідей, перш ніж вирішити, що для них найкраще.


13
Мені також буде цікаво, чи будь-які прихильники введення логіки додатків у рівень баз даних можуть запропонувати методи тестування одиниць цієї логіки програми.
Кріс Бакетт

@ChrisB: для Oracle є plunit.com/index.htm
Тоні Ендрюс

10
Бізнес-логіка, будь ласка, а не логіка додатків - ціллю повинна бути проблема області, а не вибір технології!
Phil Lello

1
@ChrisB: Маю надію, що вони можуть - заповнити таблиці даними (вам доведеться створити макет-класи на шарі програми), а потім викликати SP автоматично за допомогою сценарію. Все це може бути записано у вигляді скрипту SQL-висловлювань, очищення та налаштування по мірі його виконання. Ось посилання на 3-тестові інструменти тестування SQL: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb

Нещодавно я написав свої думки з цього приводу в своєму блозі
Гай

Відповіді:


38

Переваги в голові, переваги введення логіки в прикладний шар.

  1. Заповітність . Насправді це має бути достатньо вагомою причиною.
  2. Краща структура коду . Дотримуватися належної OO-архітектури за допомогою SQL дуже важко. Зазвичай це також полегшує обслуговування коду.
  3. Простіше кодувати . Зважаючи на всі різні мовні функції, доступні будь-якою мовою, якою ви користуєтесь, зазвичай простіше кодувати на рівні програми.
  4. Повторне використання коду . Набагато простіше ділитися кодом з бібліотеками, ніж ділитися кодом у базі даних.

5
Чи можемо ми додати також можливість плавучого джерела керувати об'єктами під час їх модифікації? Можливо, це лише моя особиста захоплення ... (так, я, очевидно, пропускаю способи, як це можна зробити ...)
jcolebrand

6
Re: 4. Чудово! Давайте використаємо цю логіку VB в моєму додатку Solaris Java ... о, чакай ...
Phil Lello

11
Філ, чудово! Давайте скористаємося вашою логікою Oracle у моєму додатку SQL Server… о, чекайте…
Крейг,

9
@Craig Реальність полягає в тому, що організації змінюють постачальників баз даних набагато рідше, ніж вони перемикають програми або мови. Однак моя думка полягала в тому, що це не перевага програми від db, не те, що db тут перевершує; є плюси та мінуси будь-якого підходу
Філ Лелло

1
@jcolebrand - Ну, якщо ви займаєтеся розробкою баз даних , то VS 2010 - це бомба. Я переходжу нашу групу з SSMS на VS для роботи з розробки і дивлюсь на прийняття цієї речі TDD, яка є цілковитою гнівом із розробленими розробниками. Це вагома інвестиція часу для будь-якого магазину, який має значну роботу з розробки баз даних (і, звичайно, нахилений до SQL Server).
Nick Chammas

11

Хоча можна використовувати управління версіями із збереженими процедурами (наприклад, інструменти бази даних Redgate інтегруються з TFS), це не завжди так прямо, як з кодом програми.

Моя позиція за замовчуванням полягає в тому, що логіка повинна зберігатися поза шаром бази даних, однак бувають випадки, коли було б ефективніше реалізувати логіку в базі даних. Якщо це так, то ви повинні переконатися, що ви можете відстежувати зміни цього коду.


4
"не так прямо, як з кодом програми", чому б ні?
NimChimpsky

@Nim - якщо я не роблю це неправильно, це стосується проектів баз даних, а не простого "редагування, і це перевірено", який ви отримуєте, коли контроль джерела інтегрується у ваш IDE.
ChrisF

1
Я б припустив, що ви можете внести зміни до вашої бази даних, не ввівши її в контроль версій, але ви дійсно не можете зробити те ж саме з кодом ...
Jaco Pretorius

5
@Jaco Ні, але ви можете запустити / випустити код, не додаючи його до SCM. Управління неохайним випуском - це неохайне управління випуском незалежно від технології, яку ви використовуєте.
Філ Лелло

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

8

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


Розширити чисельність команди досить складно, не включаючи того, хто не буде співпрацювати (не впевнений, чому відповідальна особа дозволяє цей вибір) або вимагає власного «заняття з репетиторами», щоб швидше досягти їх вимог.
JeffO

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

5
@Jeff O Чому DBA не брав участь у розробці? DBA, як правило, знають набагато більше про оптимізацію бази даних, ніж інші розробники, і їх слід розглядати як частину команди.
Філ Лелло

8
@Phil Lello: Тому що більшість розробників програмного забезпечення - це зарозумілі переслідувачі, які думають, що вони можуть самі це навчитися. Ось чому стільки баз даних є такими самими кучами сміття.
ДАЙТЕ МОЕ правильне ДУМКУ

2
Здається, що ваш dba побудував паркан навколо мінного поля, щоб захистити вас. Будьте вдячні!
Джеймс Андерсон

7

Введення логіки програми в БД звучить як погана ідея для мене. Введення логіки OTOH в БД, яка конкретно є частиною підтримання стану БД (наприклад, тригери / відростки для оновлення денормалізованих таблиць), є набагато іншою пропозицією.


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


Це. Ви хочете, щоб ваша база була стійкою. Тож логіка, пов'язана з вашими даними, повинна знаходитися там.
Арх

6

Прочитавши обидва питання, я думаю, що ми, можливо, всі пропустили одну критичну точку. Правильна відповідь може залежати від типу програмного забезпечення, яке ви розробляєте. Група DBA в значній мірі прагне працювати над критичними для бізнесу програмними системами Enterprise, і їх відповіді, як правило, відображають те, що необхідно в цьому світі. Існує величезна різниця в тому, що потрібно для цих типів додатків, ніж те, що потрібно для наступного додатку "Facebook". Неважливо, якщо ви втратите пару стінних постів, це якщо ви втратите пару замовлень чи інших фінансових операцій.

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

Підприємницькі програми також є тими, що мають, як правило, дані з багатьох місць, а база даних є єдиною спільністю. Система, в якій я працюю, має сотні різних додатків, які отримують доступ до неї, а також сотні імпорту клієнтських даних, експорт даних клієнтам та сховищам даних та використовує багатократні системи звітності. Код, який добре працює при додаванні однієї записи, не вдається, коли мені доведеться імпортувати 20 000 000. Ми змушені були один раз використовувати рівень програми, тому що тут була логіка і довелося зупинити процес через 18 годин незакінченим. Логіка, яка повинна застосовуватися до всіх записів даних у таблиці, повинна бути в базі даних, коли ви не можете мати один рівень даних, яким користуються всі.

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


4
Це найкраща відповідь. Якщо бізнес-логіка є в додатку, то, якщо є кілька додатків, що використовують різні логіки, база даних може закінчитися в дуже поганому стані.
Сем

5

Тривалий. див. Підсумок внизу.

RDBMS

RDBMS розшифровується як система управління реляційними базами даних. Це система управління реляційною базою даних. Дані зберігаються там. Дані. Це не говорить про ділову логіку.

Бізнес-процес

Що насправді означає логіка бізнесу? Для мене це опис бізнес-процесів в логічному відношенні.

Процеси - це бізнес, який регулярно відбувається, достатньо, щоб вони більше не були ad hoc. Вони різні для кожного бізнесу.

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

Бізнес

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

Швидкий об’їзд: Вам потрібно 40 мільйонів заклепок за 2 дні, ви не збираєтесь замовляти у якогось хлопця в Інтернеті рахунок PayPal, незалежно від того, наскільки дешевша його ціна, ніж у вашого звичайного постачальника.

Обробляти знання

Як ви можете собі уявити, процеси, пов’язані із створенням цієї «цінності», в основному живуть у керівниках керівництва. Деяке з них кладеться на папері та використовується як політика та процедури компанії. Деякі з них живуть у керівників корпоративних юристів. Дуже багато цього живе в голові людей, які керують підрозділами, відділами, командами та тими, хто керує машинами, касовими апаратами, печами, вантажівками. Невеликий підмножина цього коли-небудь зменшує вимоги бізнесу до програмного забезпечення, а ще менший підмножина - точний тим часом, який він впроваджується в комп'ютерні системи.

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

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

Логіка застосування

Я кажу ні. Я кажу, що логіка програми залишається всередині додатка. Дані надходять у базу даних дуже нормалізованим чином, а потім надходять ETL'd у сховище даних для звітності та буріння та згорнення, а також повороту та кубування.

Дані

Я також кажу, що дані переживають додаток, тому зусилля щодо нормалізації даних не повинні бути специфічними для додатків і навіть не для бізнесу, а повинні бути загальними для бізнесу. Чи зберігаєте коди штатів? Ви повинні використовувати INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html), оскільки це портативно для всіх підприємств. Це також спрощує для декількох додатків маніпулювати даними.

NoSQL?

Якщо ви розглядаєте базу даних як частину коду програми, від макета таблиць до тригерів, збережених процедур та форматів даних, ви по суті використовуєте корпоративну базу даних як прославлений BerkleyDB, який є прославленою структурою плоских файлів, що насправді є просто збереженими списками. Це, по суті, те, що робить NoSQL: повертаючись до коріння, але це робиться багатопроцессорним способом, стійким, не стійким до відмов.

Фактичний кодекс

Ні, вам потрібно розглядати базу даних як загальне сховище даних для декількох додатків, як поточних, так і майбутніх. Тепер ми підійшли до суті мого аргументу. Бізнес-процеси змінюються з примхами ринку, політики та моди. Дуже часто вони змінюються швидше, ніж те, що кодери можуть керувати мовами з інформатики (Java, C #, C ++ тощо) і в кінцевому підсумку записуються у VBA у таблицях Excel у бухгалтерії чи маркетингу. (І лише в тому випадку, якщо це неможливо виразити у вигадливих vlookups ...)

Деградація бази даних

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

Підсумок

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

Caveat

Я зробив свою частку dba-ing, і я прочитав відповіді на dba.se, але чесно кажучи, про що вони говорять - це питання цілісності даних та проблеми ефективності. Я повністю погоджуюся, що люди, які торкаються корпоративних даних, повинні знати, що вони роблять, будь то dba чи програміст чи старший аналітик SAS з доступом до читання / запису.

Я також зазначив, що вони рекомендують кодерам знати SQL. Я згоден. Це мова комп’ютерного програмування, тому я не бачу, чому комп'ютерні програмісти не хочуть цього знати.

Пізніше, подумавши про це

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


5
Я дійсно не дотримуюся точки деградації бази даних; вводячи логіку в базу даних, потрібно лише змінити правила в одному місці (БД) не багато додатків, написаних багатьма мовами. Однак +1 для продуманої відповіді.
Філ Лелло

3
Я мушу зазначити, що багато розробників, які вважають, що все телогічне повинно перейти в додаток, включають в це інтергретію даних. Це одна з причин того, що стільки баз даних мають погану цілісність даних. А продуктивність - один із трьох найважливіших факторів для бази даних (поряд із цілісністю та безпекою даних), тому, звичайно, ми стурбовані цим!
HLGEM

1
Дані настільки ж хороші, як і програма. Сміття в сміття і все таке. Якщо у вас є, гуді, менш точні люди, які пишуть додатки, ви можете зробити дуже мало, як DBA, щоб виправити сміття.
Крістофер Махан

1
@ChristopherMahan, у дизайні бази даних можна багато зробити, щоб запобігти поганим даним.
HLGEM

4

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

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

Один користувач на біржі стека DBA заявив про це ...

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

Останній Fortune 500, в якому я працював, мав програми, написані щонайменше на 25 мовах, що стосуються їх бази даних OLTP. Деякі з цих програм перейшли до виробництва в 1970-х.

... Далі йде його переконання, що це свідчить про порушення принципу DRY.

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

Їх база даних OLTB протягом десятиліть забезпечує надійність та ефективність даних для 25+ додатків! Це дивовижно! (Шлях!)

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

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


Добре сказано. Моя велика помилка зі збереженими процедурами, референтною цілісністю тощо - це обробка помилок. Часто кінцевому користувачеві надається "об'єкт помилки мульчування YYYY процедура XXXXXX - sqlcode -666", що призводить до того, що час витрачає виклики підтримки. Коли простий "клієнт не має податкового ідентифікатора", це дозволить користувачеві вирішити проблему і приступити до своєї роботи.
Джеймс Андерсон

3

Агностичні програми бази даних вимагають, щоб вся логіка виходила з баз даних. Дуже важко створити та підтримувати код для багатьох постачальників баз даних.


3
Дуже важко будувати сховища даних агностичних програм із логікою на основі додатків
Phil Lello

3

Хороша розробка дозволить досягти хорошого балансу між необхідністю цілісності та швидкості баз даних, додавши частину логіки в базу даних, а більшість - у додаток.

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

Переконайтесь, що поля зберігання будинків встановлені, коли рядок вставлено та оновлено - це відповідальність за DBA. Буде використаний тригер.

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

Це питання спілкування між командами та питання визнання плюсів і мінусів кожної можливості.

Моя думка: Не робіть логіку програми занадто глибокою в БД.


2

Деякі торгові системи надають спосіб розширити існуючий функціонал за допомогою скриптів, в основному розміщених у базі даних. Мій досвід щодо цього є досить негативним, принаймні в умовах для багатьох користувачів.

Ви б помістили логіку в базу даних, тому що ви хочете легко змінити цю логіку.

  • Як би ви зробили контроль версій?
    • Що таке історія коду? Які зміни були? Ким?
    • Як ви обробляли зміни на одних і тих же фрагментах коду?
  • Як би ви визначили та гарантували послідовний стан коду?

Ви можете відстежувати це в додатковому файловому VCS, але в чому тоді користь бази даних?


У будь-якому випадку весь код бази даних повинен знаходитися у контролі джерела. Це код, як і будь-який інший.
HLGEM

1

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.