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

Збережені процедури дають вам можливість повторного використання коду та інкапсуляцію (два стовпи розробки програмного забезпечення), захист (ви можете надати / відкликати дозволи на окремий збережений додаток), захистить вас від атак ін'єкцій SQL, а також допоможе зі швидкістю (хоча ця DBA сказала, що Починаючи з SQL Server 2008, навіть звичайні запити SQL складаються, якщо вони виконуються достатньо разів).

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

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

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

Деякі спостереження

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

Тільки якщо ви правильно їх використовуєте в контексті, в якому вони повинні використовуватись. Це ж твердження можна сказати про функції (в структурованому програмуванні) або методи (в об'єктно-орієнтованому програмуванні), і все ж ми бачимо функції 1К та об'єкти мегапопки.

Артефакти не дають вам цих переваг. Правильне використання цих артефактів - це те, що дає ці переваги.

безпека (ви можете надати / відкликати дозволи на окрему збережену програму),

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

захистить вас від атак ін'єкцій SQL,

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

а також допомогти зі швидкістю (хоча ця DBA сказала, що, починаючи з SQL Server 2008, навіть регулярні SQL запити складаються, якщо вони виконуються достатньо разів).

Це дуже залежить від постачальника баз даних, але загалом ваша DBA є правильною. Виписки SQL (статичні або параметризовані) збираються. SP допомагають, якщо ви хочете / вам потрібно агрегувати та обчислювати дані, які ви не можете зробити з простими операторами SQL, але тісно інтегровані з SQL і не гарантують зворотну поїздку на сервер додатків.

Хороший приклад - запит даних у тимчасовий курсор (або курсори), з якого можна запустити ще один SQL. Ви можете це робити програмно на сервері додатків, а також можете зберегти безліч об’їзних поїздок, виконавши це в db.

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

Ми розробляємо складне додаток, використовуючи методологію розробки програмного забезпечення Agile.

Спритність пов'язана з інженерними процесами та управління вимогами, а не з технологіями.

Чи може хтось придумати вагомі причини, чому вони не хочуть використовувати збережені програми?

Неправильне запитання

Питання неправильне та рівнозначне запитуванню: "Чи є вагомі причини не використовувати GOTO"? Я з цим питанням більше ставлюсь до Ніклауса Вірта, ніж до Дікстри. Я можу зрозуміти, звідки беруться настрої Дейкстри, але я не вірю, що він на 100% застосований у всіх випадках. Те саме з магазинами програм та будь-якими технологіями.

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

Правильне запитання полягає в тому, "якого типу використання збережених процедур слід уникати". Або "за яких умов я повинен (або не повинен) використовувати збережені процедури" . Шукати причин не використовувати технологію - це просто покласти провину на інструмент, а не накладати відповідальність на інженер прямо на місце, де воно належить - інженеру.

Іншими словами, це вигнання чи заява про незнання.

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

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

Що робити у вашому випадку?

Мій досвід, коли я перебуваю в Римі, роби так, як роблять римляни .

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

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

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

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

Моя думка про те, як їх не використовувати

• Не перекладайте складну логіку за межі збору даних (і, можливо, деяких перетворень). Добре вводити в них деяку логіку масажування даних або збирати з ними результат декількох запитів. Але саме про це. Все, що виходить за рамки цього, може кваліфікуватися як бізнес-логіка, яка повинна знаходитися десь в іншому місці.

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

• Не робіть бази даних єдиним місцем, де містяться документи вашого магазину. До ваших облікових записів магазину слід ставитися так само, як і до вихідного коду C # або Java. Тобто джерело контролює текстове визначення ваших програм магазину. Люди звикають, що магазини програм не можуть бути контрольовані джерелами - булкрап, вони просто не знають, про яке криваве пекло вони говорять.

Моя думка про те, як / де їх використовувати

• У вашій програмі потрібні дані, які потрібно перемістити або агрегувати з декількох запитів або переглядів. Ви можете вивантажити це з програми в db. Тут ви повинні зробити аналіз продуктивності, оскільки: a) двигуни баз даних ефективніші, ніж сервери додатків у цьому, але б) сервери додатків (іноді) простіше масштабувати по горизонталі.

• Точний контроль доступу зерна. Ви не хочете, щоб у вашому db приєднувались ідіоти, які працюють декартовими, але ви також не можете просто заборонити людям виконувати довільні заяви SQL так само. Типовим рішенням є дозволити довільні заяви SQL у середовищах розробки та UAT, забороняючи їх у системних та виробничих середовищах. Будь-яке твердження, яке повинне зробити його систематизованим або виготовленим, переходить у процедуру магазину, переглядається кодом як розробниками, так і dbas.

Будь-яка дійсна необхідність запускати оператор SQL, який не знаходиться в магазині Pro, проходить через інше ім'я користувача / обліковий запис та пул з'єднань (із використанням, яке дуже відстежується та відсторонено)

• У таких системах, як Oracle, ви можете отримати доступ до LDAP або створити посилання на зовнішні бази даних (скажімо, виклик магазину Pro на db ділового партнера через vpn.) Простий спосіб зробити код спагетті, але це справедливо для всіх парадигм програмування, а іноді у вас є конкретні вимоги щодо бізнесу / середовища, для яких це єдине рішення. Програми магазину допомагають інкапсулювати цю неприємність лише в одному місці, близько до даних та без необхідності переходити на сервер додатків.

Незалежно від того, чи будете ви це запускати на db в магазині або на сервері додатків, залежить аналіз компромісу, який ви, як інженер, повинні зробити. Обидва варіанти мають бути проаналізовані та обґрунтовані деяким типом аналізу. Так чи інакше, просто звинувачуючи іншу альтернативу як "погану практику", це лише кульгавий технічний коп.

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

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

Сподіваюся, це допомагає.

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

(збережені процедури) захищають вас від атак ін'єкцій SQL

Це насправді параметризований запит, який захищає вас, який ви можете легко виконати в простому текстовому запиті sql.

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

• Логіка бізнесу та додатків повинна бути в коді, а не в базі даних. Введення логіки в БД викликає занепокоєння.
• Ви не можете перевіряти збережені програми так само легко, як код у звичайних тестових проектах одиниць, з іншою логікою програми.
• Я не знаходжу збережені програми як сприятливі для перевірки першого програмування під час написання коду.
• Зберігати документи не так просто налагоджувати, як код програми, коли ви налагоджуєте програму в IDE.
• Контроль версій / Контроль джерела SP щодо звичайного коду

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

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

захистить вас від атак ін'єкцій SQL,

Ні, вони не. Я навіть не можу почати здогадуватися, звідки ця ідея могла взятися, як я чую, як це часто говорилося, і це просто неправда. Це може пом'якшити деякі типи атак на ін'єкцію SQL, але якщо ви не використовуєте в першу чергу параметризовані запити, це не має значення. Я все ще можу '; ЗРОБИТИ ТАБЛИЧНІ акаунти; -

а також допомогти зі швидкістю (хоча ця DBA сказала, що, починаючи з SQL Server 2008, навіть регулярні SQL запити складаються, якщо вони виконуються достатньо разів).

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

Тільки причина використовувати збережену процедуру, ІМХІ, коли ви повинні зробити складний, мульти-ступінчастим запит , який витягує з декількох розбору джерел. SP не повинні містити логіку рішення низького рівня, і вони ніколи не повинні просто інкапсулювати інший простий запит. Немає переваг і є лише багато недоліків.

Слухайте свою DBA. Він знає, що сталося.

Це була офіційна лінія, коли я кілька років тому працював на одній з Великих п’яти. Обґрунтуванням було те, що оскільки SP прив’язані до конкретних реалізацій (PL / SQL vs T / SQL vs ...), вони надмірно обмежують вибір технологій.

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

Усі три компанії, в яких я працюю, використовували збережені процедури для логіки їх застосування із SQL Server. Я не дуже бачив речі по-іншому. Але для мене це великий безлад. Зазвичай не дуже хороші засоби поводження з помилками або засоби повторного використання коду із збереженими процедурами.

Скажімо, у вас є збережена процедура, яка повертає набір даних, який ви хочете використовувати, як ви можете використовувати їх у майбутніх збережених процедурах? Механізми на SQL Server для цього не дуже хороші. EXEC INTO ... працює лише на одному або двох рівнях гніздування (я зараз забуваю). Або вам потрібно заздалегідь визначити робочий стіл і ввести його в процес обробки. Або вам потрібно заздалегідь створити таблицю темпів та заповнити процедуру. Але що робити, якщо двоє людей називають тимчасовою таблицею одне і те ж у двох різних процедурах, які вони ніколи не планували використовувати одночасно? У будь-якій нормальній мові програмування ви можете просто повернути масив з функції або вказати на об'єкт / глобальну структуру, що поділяється між ними (за винятком функціональних мов, де ви б повернули структуру даних на відміну від простої зміни глобальної структури ... )

Як щодо повторного використання коду? Якщо ви почнете вводити загальні вирази в UDF (або ще гірші підзапити), ви уповільнить код. Ви не можете викликати збережену процедуру для обчислення для стовпця (якщо ви не використовуєте курсор, передайте значення стовпців по одному, а потім якось оновіть таблицю / набір даних). Таким чином, щоб отримати максимальну продуктивність, вам потрібно вирізати / вставити загальні вирази в усьому місці, який є кошмаром технічного обслуговування ... За допомогою мови програмування ви можете створити функцію для генерації загального SQL, а потім викликати його звідусіль під час створення рядок SQL Тоді, якщо вам потрібно відкоригувати формулу, ви можете внести зміни в одне місце ...

Як щодо обробки помилок? У SQL Server є багато помилок, які негайно зупиняють виконання збереженої процедури, а також деякі, які навіть змушують відключитись. З 2005 року існує спроба / ловити, але все ж є ряд помилок, які неможливо знайти. Також те ж саме відбувається і з дублюванням коду в коді обробки помилок, і ви дійсно не можете пропускати винятки так легко, або перекидати їх на більш високі рівні так само легко, як і більшість мов програмування .....

Також просто швидкість. Багато операцій над наборами даних не орієнтовані на SET. Якщо ви намагаєтеся робити речі, орієнтовані на рядки, або збираєтесь використовувати курсор, або ви будете використовувати "курсор" (коли розробники часто запитують кожну рядок по черзі і зберігають вміст у змінних @ так само, як курсор. .. Хоча це часто повільніше, ніж курсор FORWARD_ONLY). З SQL Server 2000 у мене було щось, що працювало протягом 1 години, перш ніж я його вбив. Я переписав цей код у Perl, і він закінчився за 20 хвилин. Коли мова сценаріїв на 20-80 разів повільніше, ніж C, димить SQL у продуктивності, у вас точно немає операцій із написання рядків, орієнтованих на бізнес у SQL.

Тепер у SQL Server є інтеграція CLR, і багато цих проблем усуваються, якщо ви використовуєте CLR-процедури, що зберігаються. Але багато DBA не знають, як писати .NET програми або вимикати CLR через проблеми безпеки та дотримуватися Transact SQL .... Також навіть у CLR у вас все ще є проблеми обміну даними між декількома процедурами ефективно .

Крім того, загалом, найважче масштабувати - це база даних. Якщо вся ваша бізнес-логіка знаходиться в базі даних, тоді, коли база даних стане надто повільною, у вас виникнуть проблеми. Якщо у вас є бізнес-рівень, ви можете просто додати більше кешування та більше бізнес-серверів для підвищення продуктивності. Традиційно інший сервер для встановлення Windows / linux та запуск .NET / Java набагато дешевший, ніж придбання іншого сервера баз даних та ліцензування більше SQL Server. Зараз у SQL Server є більш підтримка кластеризації, але спочатку її взагалі не було. Тож якщо у вас є багато грошей, ви можете додати кластеризацію або навіть зробити доставку журналу, щоб зробити кілька копій, які лише читаються. Але в цілому це буде коштувати набагато більше, ніж просто мати запис за кешем чи щось.

Також подивіться засоби Transact-SQL. Рядок маніпуляції? Я прийму заняття Java String Class / Tokenizer / Scanner / Regex в будь-який день. Таблиці хешу / пов'язані списки / тощо. Я візьму рамки колекції Java і т.д. ... І те саме для .NET ... І C #, і Java є значно розвиненішими мовами, ніж Transact SQL ... Хек-кодування з Transact-SQL змушує мене заздрити С. .

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

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

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

В цілому, я думаю, що SQL і Transact SQL - це чудові мови для запитів / оновлення даних. Але для кодування будь-якого типу логіки, виконуючи маніпуляції з рядком (або маніпулюючи файлами маніпуляцій .... ви здивуєтеся, що ви можете зробити з xp_cmdshell ....), будь ласка, ні. Я сподіваюся знайти майбутнє місце, яке здебільшого не використовує збережені процедури. З точки зору ремонту коду, вони є кошмаром. Крім того, що станеться, якщо ви хочете перейти на платформи (хоча насправді, якщо ви заплатили за Oracle / DB2 / Sybase / Sql сервер / тощо.), Ви можете отримати все, що ви можете, використовуючи кожне власне розширення, яке вам допоможе. ..).

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

Як ви виконуєте версію збережених процедур на сервері?

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

Збережені процедури не можна змінювати безпосередньо на сервері, інакше як ви знаєте, що зараз працює _right? Якщо їх немає, інструмент розгортання потребує доступу для запису збережених процедур у базу даних. Вам доведеться розгортати кожну збірку (план виконання може бути іншим)

Хоча збережені процедури не є портативними, взагалі немає SQL (коли-небудь бачила обробку дат Oracle - uggghhh).

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

Це так суперечить усьому, що я дізнався.

Можливо, вам доведеться вийти більше. [усмішка] Серйозно, що зберігаються програми припадають принаймні 10 років. Практично з тих пір, як n-ярус замінив клієнт-сервер. Занепад прискорився лише прийняттям таких мов OO, як Java, C #, Python тощо.

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

Збережені процедури дають можливість повторного використання коду та інкапсуляції (два стовпи розробки програмного забезпечення)

Дуже правильно. Але це так само пристойно зорієнтований шар OO.

безпека (ви можете надати / відкликати дозволи на окремі збережені програми)

Хоча ви можете це зробити, мало хто робить це через серйозні обмеження. Безпека на рівні БД недостатньо деталізована для прийняття контекстних рішень. Через ефективність роботи та управління накладними можливостями також є підключення для кожного користувача - тому вам все одно потрібен певний рівень авторизації у коді додатка. Ви можете використовувати вхідні дані на основі ролей, але вам потрібно буде створити їх для нових ролей, підтримувати, яку роль ви виконуєте, перемикати з'єднання, щоб виконувати роботу на "системному рівні", як ведення журналів тощо. І, врешті-решт, якщо ваша програма є власністю - таким є і ваше з'єднання з БД.

захистить вас від атак ін'єкцій SQL

Не більше, ніж робити параметризовані запити. Що вам все одно потрібно робити.

а також допомогти зі швидкістю (хоча ця DBA сказала, що, починаючи з SQL Server 2008, навіть регулярні SQL запити складаються, якщо вони виконуються достатньо разів).

Я думаю, що це почалося в MSSQL 7 або 2000 р. Було багато дискусій, вимірювань та дезінформації щодо збережених процесорів проти вбудованої продуктивності SQL - я збиваю це все під YAGNI. І, якщо вам це потрібно, протестуйте.

Ми розробляємо складне додаток, використовуючи методологію розробки програмного забезпечення Agile. Чи може хтось придумати вагомі причини, чому вони не хочуть використовувати збережені програми?

Я не можу думати про багато причин , ви хочете , щоб. Java / C # / будь-яка мова 3-го GL - все набагато більш здатні, ніж T-SQL, при інкапсуляції, повторному використанні та чутливості тощо. Більшість з них безкоштовно надаються напівпристойним ORM.

Також, даючи пораду "розповсюджувати по мірі необхідності, але не більше" - я думаю, що тягар доказування в наші дні лежить на захисниках СП. Поширеною причиною того, що зберігати складний процес важко, є те, що T-SQL простіше, ніж OO, і магазин має кращі розробники T-SQL, ніж OO. Або, що DBA зупиняється на рівні бази даних, а збережені програми є інтерфейсом між розробником та DBA. Або ви доставляєте напівфантазований продукт, і збережені документи можуть бути налаштовані користувачем. Якщо немає таких міркувань, я думаю, що за замовчуванням для будь-якого проекту Agile SW в наші дні буде ORM.

Враховуючи всі вищезазначені випадки, я хотів би додати ще один. Вибір ІП може залежати і від вибору людей.

Я особисто відчуваю розчарування, коли люди вкладають в ІП дуже складну логіку, і я вважаю, що такі ІП дуже складні для підтримки та налагодження. Навіть у багатьох випадках сам розробник стикається з проблемою, коли налагодження коду позаду (скажімо, мовна частина) набагато простіше, ніж у SP.

SP слід використовувати лише для простих операцій. Ну, це мій вибір.

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

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

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

Тож на протилежну сторону.

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

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

3. Зміни інтерфейсів дещо проблематичні із збереженими процедурами з причини № 1 вище, але це може стати дуже великим кошмаром, якщо задіяна велика кількість клієнтських додатків.

Вищезазначене досить важко заперечити. Вони бувають. У всіх, про-СП та анти-СП, мабуть, були страшилки щодо цього. Проблеми не є нерозв’язними, але якщо ви не звертаєте на них уваги, їх не вдається вирішити (у LedgerSMB ми використовуємо сервіс-локатор для динамічного збирання SP-дзвінків під час виконання, повністю уникаючи вказаних вище проблем. Поки ми PostgreSQL лише щось подібне можна було б зробити для інших db).

Про позитиви. Припускаючи, що ви можете вирішити вищезазначені проблеми, ви отримуєте:

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

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

3. Повторне використання запиту.

О та кілька речей, які ви майже ніколи не повинні робити на ІП:

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

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

на кого ти працюєш?

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

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

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

Для (багато) більшої дискусії з обох боків огорожі читайте дискусію на кодування жаху . FWIW Я схиляюся на бік тих, хто виступає за СП.

Дуже важко перемикати бренди баз даних та використовувати однакові збережені процедури.

У вашої команди або немає DBA, і ніхто більше не хоче мати нічого спільного з sql.

Це не що інше, як змагання програмістів v DBA.

ІМО це залежить. Збережені процедури мають своє місце, але вони не є найкращою практикою, і не варто чогось уникати будь-якою ціною. Розумний розробник знає, як правильно оцінити дану ситуацію і визначити, чи є відповідь на збережену процедуру. Особисто я прихильник використання ORM якихось типів (навіть базових, таких як необроблений Linq до Sql), а не збережених процедур, за винятком, можливо, попередньо визначених звітів чи подібних, але знову ж таки це дійсно в кожному конкретному випадку.

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

Однак, я знаю, що компанії, які працюють дуже добре, вкладають всю бізнес-логіку в PL / SQL пакети, що живуть у базі даних. Це не дуже великі програми, але теж не банальні; скажімо, 20K-100K LOC. (PL / SQL краще підходить для такої системи, ніж T-SQL, тому, якщо ви знаєте лише T-SQL, ви, ймовірно, хитаєте головою в невірі зараз ...)

Це ще один момент, про який ще не говорилося:

Інструменти генерації коду та інструменти зворотного інжинірингу справді не справляються із збереженими процедурами. Інструмент, як правило, не може сказати, що робить прок. Чи повертає програму набір результатів? Кілька наборів результатів? Чи отримує його набір результатів з декількох таблиць і тимчасових таблиць? Чи є Proc просто інкапсульованою заявою оновлення і нічого не повертає? Чи повертає він набір результатів, значення повернення та деякий "консольний вихід"?

Отже, якщо ви хочете використовувати інструмент для автоматичного створення об'єкта DTO і DAO-об'єкта для передачі даних (як, наприклад, "конструктор служб" liferay), ви не можете це легко зробити.

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

Програмуючи соло, я не можу протистояти написанню збережених процедур.

Я в основному використовую MySQL. Я раніше не використовував об'єктно-орієнтовані бази даних, як, наприклад, PostGreSQL, але те, що я в змозі зробити з SP в MySQL, це трохи відтягнути структуру таблиці. SP дозволяють мені розробити ці примітивні дії, входи та виходи яких не зміняться , навіть якщо база даних, що знаходяться під ним , змінюється.

Отже, у мене називається процедура logIn. Коли ви входите в систему, ви завжди просто проходите usernameі password. Результат, переданий назад, - ціле число userId.

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

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

Я погоджуюся з Марком, що громада вже досить давно відходить від збережених процедур. Незважаючи на те, що багато пунктів, на яких піднімався оригінальний плакат, чому ми, можливо, хочемо використовувати SP, були дійсними свого часу, минуло досить багато часу, і, як сказав інший плакат, середовище змінилося. Наприклад, я пам’ятаю, що одним із аргументів ЗА використання СП «назад у той день» було досягнуто підвищення продуктивності, оскільки їх плани виконання були «заздалегідь складені», тоді як динамічний SQL з нашого коду повинен був «перекомпілюватися» при кожному виконанні. Це вже не так, оскільки основні бази даних змінювалися, вдосконалювалися, адаптувалися тощо.

Але це означає, що ми використовуємо SP в моєму поточному проекті. Причина полягає лише в тому, що ми будуємо нові програми на основі існуючої бази даних, яка все ще підтримує застарілі програми. Як результат, змінити схему дуже важко, поки ми не вимкнемо застарілі програми. Ми прийняли свідоме рішення розробити наші нові програми на основі поведінки та правил, необхідних для програми, та використовувати SP для тимчасового взаємодії з базою даних так, як ми хотіли б, і дозволимо SP-серверам адаптуватися до існуючих SQL . Це стосується попереднього плаката, що SP-програми полегшують внесення змін на рівні бази даних, не вимагаючи змін до коду програми. Використання SP-файлів як реалізації шаблону адаптера, безумовно, має для мене сенс (особливо, враховуючи мій поточний проект),

Fwiw, ми маємо намір видалити SP, коли схема оновлюється. Але, як і у всьому іншому в корпоративному розвитку, ми побачимо, чи це станеться! [усмішка]

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

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

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

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

Збережені процедури "для мене" підходять для операцій OLAP "лише для читання", рідкісне використання.

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

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

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

Вибирайте свої інструменти розумно, і ви врятуєте себе в світі рани з часом.