Які плюси та мінуси збереження SQL у Stored Procs проти коду [закрито]

Які переваги / недоліки зберігання SQL у вихідному коді C # або в Збережених програмах? Я обговорював це з другом у проекті з відкритим кодом, над яким ми працюємо (C # ASP.NET Forum). На даний момент більша частина доступу до бази даних здійснюється шляхом побудови вбудованого SQL у C # та виклику до БД SQL Server. Тому я намагаюся встановити, що саме для цього конкретного проекту було б найкращим.

Поки що я маю:

Переваги для Кодексу:

• Простіше в обслуговуванні - не потрібно запускати SQL-скрипт для оновлення запитів
• Простіше перенести порт до іншої БД - жодних програм для порту

Переваги для збережених програм:

• Продуктивність
• Безпека

Я не прихильник збережених процедур

Збережені процедури БІЛЬШЕ ремонтопридатні, оскільки: * Вам не доведеться перекомпілювати додаток C #, коли ви хочете змінити SQL

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

• Ви в кінцевому підсумку повторно використовуєте SQL-код.

Мови програмування, включені на C #, мають цю дивовижну річ, яку називають функцією. Це означає, що ви можете викликати один і той же блок коду з кількох місць! Дивовижний! Потім ви можете помістити повторно використовуваний код SQL всередині одного з них, або якщо ви хочете отримати справді високі технології, ви можете використовувати бібліотеку, яка робить це за вас. Я вважаю, що їх називають Об'єктними реляційними картами, і вони досить поширені в наші дні.

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

Домовились, ось чому зберігаютьсяпрограми - це погана річ. Набагато простіше перефактурувати та розкласти (розбити на менші частини) код на функції, ніж SQL на ... блоки SQL?

У вас є 4 веб-сервери та купа програм для Windows, які використовують один і той же код SQL. Тепер ви зрозуміли, що з кодом SQl є невелика проблема, тому ви краще ...... поміняйте програму на 1 місце або надішліть код усім веб-сервери, перевстановіть усі програми для настільних ПК (клік може допомогти) на всіх вікнах Windows

Чому ваші програми Windows підключаються безпосередньо до центральної бази даних? Це здається ВЕЛИЧЕЗЬОМУ безпековій дірі саме там і вузьким місцем, оскільки це виключає кешування на стороні сервера. Чи не повинні вони підключатися через веб-сервіс чи подібні до ваших веб-серверів?

Отже, натисніть 1 новий проросток або 4 нових веб-серверів?

У цьому випадку це простіше натиснути одну нову sproc, але з мого досвіду, 95% від «підштовхнули змін» впливають на код , а не бази даних. Якщо в цьому місяці ви підштовхуєте 20 речей до веб-серверів, а 1 - до бази даних, ви навряд чи втратите багато, якщо замість цього наштовхнути на речей 21 сервер, а нуль - на базу даних.

Легше переглядати код.

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

Більше мінусів:

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

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

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

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

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

[Редагувати] Ось ще одне поточне обговорення

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

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

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

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

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

Переваги для Кодексу:

• Простіше в обслуговуванні - не потрібно запускати SQL-скрипт для оновлення запитів
• Простіше перенести порт до іншої БД - жодних програм для порту

Насправді, я думаю, у вас це є назад. IMHO, SQL у коді - це біль для підтримки, оскільки:

• ви в кінцевому підсумку повторюєте себе у пов'язаних блоках коду
• SQL не підтримується як мова в багатьох IDE, тому у вас є лише ряд рядків, що перевіряються на помилки, виконуючи завдання для вас
• зміни типу даних, імені таблиці чи обмежень є набагато більш поширеними, ніж заміна цілих баз даних на нову
• рівень вашої складності зростає, коли ваш запит зростає складністю
• і тестування вбудованого запиту вимагає побудови проекту

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

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

КОН

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

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

ПРОС

1. Ефективність того, що може бути вартим (уникає розбору запитів за допомогою драйвера / планування відпочинку тощо)
2. Маніпуляція з даними не вбудована в код C / C ++ / C #, що означає, що я маю менше коду низького рівня для перегляду. SQL є менш багатослівним і простішим у перегляді, якщо вони перераховані окремо.
3. Завдяки розлуці люди зможуть знайти та повторно використовувати SQL-код набагато простіше.
4. Простіше змінити речі, коли зміниться схема - потрібно просто дати однаковий вихід коду, і він буде працювати чудово
5. Простіше переносити порт до іншої бази даних.
6. Я можу перелічити окремі дозволи на мої збережені процедури та контролювати доступ на цьому рівні.
7. Я можу профілювати свій запит / код збереження даних окремо від коду перетворення даних.
8. Я можу реалізувати змінні умови в моїй збереженій процедурі, і це буде легко налаштувати на сайті клієнта.
9. Стає легше використовувати деякі автоматизовані інструменти для перетворення моєї схеми та висловлювань разом, а не тоді, коли вона вбудована в мій код, де мені доведеться їх вишукувати.
10. Забезпечення кращих практик доступу до даних простіше, якщо у вас є весь код доступу до даних всередині одного файлу - я можу перевірити наявність запитів, що мають доступ до неефективної таблиці, або того, що використовує більш високий рівень серіалізації або виберіть * у коді тощо .
11. Стає легше знайти зміни схеми / зміни логіки маніпулювання даними, коли всі вони перераховані в одному файлі.
12. Зробити пошук та заміну редагувань у SQL стає простіше, коли вони знаходяться там же, наприклад змінити / додати заяви про ізоляцію транзакцій для всіх збережених програм.
13. Я та хлопець DBA вважаємо, що мати окремий файл SQL легше / зручніше, коли DBA повинен переглянути мої SQL речі.
14. Нарешті, вам не доведеться турбуватися про атаки ін'єкцій SQL, оскільки деякі ледачі члени вашої команди не використовували параметризовані запити під час використання вбудованих sqls.

Перевага продуктивності для збережених процедур часто незначна.

Більше переваг для збережених процедур:

• Запобігання зворотній інженерії (якщо, звичайно, створено за допомогою шифрування)
• Краща централізація доступу до бази даних
• Можливість прозоро змінювати модель даних (без необхідності розгортання нових клієнтів); особливо зручно, якщо кілька програм мають доступ до однієї моделі даних

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

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

Збережені процедури.

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

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

Переваги зберігаються процедур :

Легше переглядати код.

Менш сполучені, тому легше тестуються.

Легше налаштовується.

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

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

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

Недоліки:

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

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

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

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

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

Великий шанувальник Transact SQL, налаштування великих запитів виявився для мене дуже корисним. Близько 6 років не писав жодного вбудованого SQL!

Ви перераховуєте 2 точки для паростків:

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

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

Це все-таки найкраща практика для роботи.

Linq - це, безумовно, шлях, який я б зараз пішов на новий проект. Дивіться подібний пост .

@Keith

Безпека? Чому проростки були б більш безпечними?

Як запропонував Komradekatz, ви можете заборонити доступ до таблиць (для комбінації імені користувача / пароля, що підключається до БД) та дозволити доступ лише до SP. Таким чином, якщо хтось отримує ім’я користувача та пароль до вашої бази даних, він може виконати SP, але не може отримати доступ до таблиць або будь-якої іншої частини БД.

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

Думай про це так

У вас є 4 веб-сервери та купа програм для Windows, які використовують один і той же код SQL. Тепер ви зрозуміли, що з кодом SQl є невелика проблема, тому ви краще ...... поміняйте програму на 1 місце або надішліть код усім веб-сервери, перевстановіть усі програми для настільних ПК (клік може допомогти) на всіх вікнах Windows

Я віддаю перевагу збереженим документам

Так само простіше зробити тестування продуктивності на додаток, помістити його в статистику набору аналізаторів запитів io / time on set showplan_text on і voila

не потрібно запускати профілер, щоб точно бачити, що викликається

тільки мої 2 копійки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ми використовуємо збережені процедури з БД Oracle, де я зараз працюю. Ми також використовуємо Subversion. Усі збережені процедури створюються у форматі .pkb & .pks та зберігаються в Subversion. Я раніше робив Inline Line SQL, і це біль! Я дуже віддаю перевагу тому, як ми це робимо тут. Створення та тестування нових збережених процедур набагато простіше, ніж це робити у вашому коді.

Є

Менші колоди

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

Я не є великим прихильником збережених процедур, але використовую їх в одній умові:

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

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

Але людино, їм так страшно керувати. Я уникаю їх, наскільки я можу.

Програми, що зберігаються в SQL, не підвищують продуктивність запиту

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

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

Збережені процедури БІЛЬШЕ ремонтопридатні, оскільки:

• Вам не потрібно перекомпілювати додаток C #, коли ви хочете змінити SQL
• Ви в кінцевому підсумку повторно використовуєте SQL-код.

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

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

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

Простіше перенести порт до іншої БД - жодних програм для порту

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

@ Террапін - зірочки настільки ж вразливі до нападів ін'єкцій. Як я сказав:

Завжди параметризуйте всі запити - ніколи не вбудовуйте щось із вводу користувача, і ви будете добре.

Це стосується паростків та динамічного Sql.

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

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

Моє запитання було б: якщо весь доступ до нього через ваш додаток, використовуючи з'єднання та користувачі з обмеженими правами на оновлення / вставлення тощо, додає цей додатковий рівень безпеки чи додаткового адміністрування?

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

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

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

Незважаючи на це, мови, які використовуються для запису збережених процедур (PL / SQL є відомим прикладом), є досить жорстоким. Зазвичай вони не пропонують жодних вигод, які ви побачите у популярних сучасних імперативних, OOP або функціональних мовах. Подумайте COBOL.

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

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

Багато було сказано в попередніх відповідях про переваги безпеки збережених програм. Вони поділяються на дві широкі категорії:

1) Обмеження прямого доступу до даних. Це, безумовно, важливо в деяких випадках, і якщо ви стикаєтесь з одним, то збережені програми - це майже ваш єдиний варіант. На мій досвід, такі випадки є швидше винятком, ніж правилом.

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

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

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

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