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

Які основні причини ( крім "незалежності баз даних" ) полягають у тому, що більшість ІТ-проектів сьогодні ігнорують багатство функцій, що існують у сучасних механізмах баз даних, таких як Oracle 11g та SQL Server 2008?

Або запозичити з блогу Гельсінкської декларації, який пише це так:

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

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

Ми говоримо про такі речі

• Збережені процедури, що використовуються як API даних (для безпеки та уникнення надмірного мережевого трафіку)
• Матеріалізовані погляди
• Замість тригерів
• Ієрархічні запити (підключити за)
• Географія (просторові типи даних)
• Аналітика (потенційний клієнт, відставання, зведення, куб тощо)
• Віртуальна приватна база даних (VPD)
• Аудит на рівні бази даних
• Запити щодо зворотного зв’язку
• Генерація XML та перетворення XSL у базі даних
• Виноски HTTP з бази даних
• Фонове планувальник завдань

Чому ці функції не використовуються? Чому більшість розробників Java, .NET та PHP дотримуються підходу "SELECT * FROM mytable"?

Оскільки збережені процедури:

• додати іншу мову розробки, збільшуючи складність і потенційно надлишковий код (логіка написана обома мовами);
• як правило, мають гірші можливості інструментарію, моніторингу та налагодження, ніж PHP, C #, Java, Python тощо;
• як правило, менш здатні, ніж більшість мов середнього рівня;
• мають перевагу лише у великому обсязі трансформації даних (де ви уникаєте зворотного зв’язку із сервером), яке, як правило, є лише мінімальним фактичним використанням.

З огляду на це, це загальноприйнята методологія для програм C # ASP.NET.

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

Я часто використовував матеріалізовані подання, а іноді використовував CONNECT BY в Oracle, жоден з яких, на мою думку, не існує в MySQL.

Я не схильний використовувати XML / XSLT в базі даних, оскільки, ну, це означає, що я використовую XML і XSLT.

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

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

Оскільки розробники не знають про SQL. Вони покладаються на DDL і DML, створені такими інструментами, як Hibernate, та конструкціями рівня мови, такими як анотації JPA. Розробникам байдуже, чи вони жахливо неефективні, тому що їх милосердно приховують звичайні рівні журналів і тому, що адміністратори баз даних не є частиною команд розробників.

Тому мені подобаються інструменти iBATIS . Вони змушують писати та розуміти SQL, включаючи особливості СУБД.

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

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

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

Msgstr "Чому функції бази даних ігноруються".

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

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

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

MySQL.

Коли в кінці 1990-х та на початку 2000-х років веб-програми вибухнули, MySQL знаходився у версії 3.3 або 4.0 і не підтримував нічого вище простих SELECTs. Однак він був безкоштовним і встановлювався з більшістю дистрибутивів Linux. Як результат, покоління програмістів не дізналося про бази даних і не знає, як ними користуватися.

Навіть зараз, коли MySQL перебуває на рівні 5.1 і підтримує більшість функцій комерційної системи, ті самі брудні старі блоги та статті використовуються як шаблони при запуску нового проекту LAMP, а MySQL розгортається з таблицями MyISAM та функціональністю 3,3-епохи. .

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

Прості смертні зазнають невдачі навіть з найпростішою мовою. Можливо, 1 із 10 людей має навички користуватися простою мовою, такою як C #. Але з цих 10% лише 1 із 10 або 1% усіх людей може ефективно використовувати такі мови, як SQL або Haskell.

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

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

Виправити / передислокувати середній рівень простіше, ніж СУБД.

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

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

Вони вивчають мінімальний мінімум SQL, щоб обійтись, і не усвідомлюють всіх різних розширень, які пропонують різні СУБД.

В одному проекті я хотів би мати матеріалізовані погляди ... але я використовую Postgres. Я хотів би використовувати просторові типи даних для іншого проекту, але мені доведеться зламати або змінити бази даних, щоб мати справу з наполяганням mySQL, щоб вони не були нульовими. Мені навіть довелося розібратися, як відключити послідовність транзакцій Oracle, щоб мати справу з тривалими запитами на OLTP, що не було б проблемою в mySQL.

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

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

(і не сприймайте це як підтримку для отримання сертифікації DBA ... Я знав деякі Oracle DBA, які не змогли запрограмувати собі шлях з мокрого мішка; я пройшов усі курси протягом 8i днів, але відмовився здавати тести, оскільки я не хотів потрапляти до цієї групи)

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

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

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

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

Я потрапляв у занадто багато ситуацій, коли корпоративна політика ("ми не маємо доступу до SQL Server, тому дозволяє встановлювати менш потужну СУБД, таку як Access, обробляти мільйони рядків і об'єднувати її з мільйонами рядків в іншій таблиці, і дозволяє автоматизувати цей імпорт .. ") або навіть технічна політика, яка може відбутися (" Я знаю, що Access може обробляти такий обсяг даних, і навіть якщо цього не відбувається, ми можемо розділити MDB на кілька MDB і посилатися на них ..... ")

UGH. Корпоративна політика та технічна політика або навіть незнання завадили мені використовувати багато функцій.

Інший приклад - я не бачу причин , щоб не використовувати збережені процедури в 100% Microsoft магазин , де SQL Server є те СУБД вибору. Але, оскільки ІТ-спеціаліст, котрий врешті-решт збирався отримати рішення, був «легким» для ІП, мені довелося вдатися до інших заходів. Я маю на увазі, є прекрасний приклад того, чому деякі ці "особливості" проігнорувались ними у своєму магазині.

Я знаю ще один магазин, який досі використовує DOS Foxpro 2, оскільки їх єдиний ІТ-спеціаліст написав існуючу систему таким чином, і саме так будуть розроблятися всі нові речі. Чому? Чи не можемо ми рухатися разом із часом? У багатьох людей, що займаються маркетингом, одразу відкрито кілька підказок DOS, в них працюють "робочі місця" Foxpro, які видають найпотворніші звіти, які я коли-небудь бачив. Але це працює - я їм це дам. Це працює - у них 12 мільйонів рядків у головній таблиці та 50+ інших таблиць, які вони `` приєднують '' до цієї основної таблиці (очевидно, не всі 50 одночасно), але людина ... вже минув 1991 рік! Вони навіть не хочуть обговорювати один пункт із того списку маркерів, який ви вказали у своєму питанні.

Такі речі, тому я думаю.

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

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

Приємне запитання та хороша дискусія.

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

Це справді дивний стан справ: ми приховуємо та продублюємо функціональність БД в ActiveRecord, Hibernate та інших проміжних системах. Але це те, що відбувається з парадигмами в точці поломки ("Невідповідність об'єктно-реляційного імпедансу"). Чи перейдемо ми коли-небудь до технологій баз даних, подібних до наших додатків OO (наприклад, об'єктних БД)?

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

Інше питання: "навіщо мені це робити в БД, якщо це може робити середній рівень?" Середній рівень знайомий і постійно завойовує швидкість та функціональність. Знову ж таки, ми використовуємо середній рівень, щоб уникнути невідповідності OO-RDMS.

Щоб продовжити те, що сказав Крістіан , щодо масштабованості.

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

Раніше, у класичні часи Fat Apps та Client Server, DB і Application Server були в основному одним і тим же. У вас була логіка програми, або вбудована у ваш жирний клієнтський код, або ви повернули її назад до СУБД. Але тоді основною формою спілкування був SQL безпосередньо до бази даних.

У наш час інші протоколи додатків є більш поширеними (CORBA, DCOM, Remote EJB та все більш поширені сьогодні протоколи стилів XML / JSON / HTTP-RPC через HTTP). Більшість баз даних не реагують на ці протоколи безпосередньо, тому рівень програми вставляється, щоб перехопити ці виклики, і цей рівень викликає базу даних.

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

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

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

Однак навіть тоді третій рівень надзвичайно допомагає додавати гнучкість сучасній системі.

Для мене причина не в тому, що мої програми є агностичними, але база даних найкраще формує основні функції CRUD. Так, бази даних високо оптимізовані, і, можливо, вони зможуть створити протокол HTTP, але чому ви це робите? Веб-служба / веб-програма оптимізована для HTTP-дзвінків, а не бази даних. Так само, як додаток не призначений для безпосереднього підключення до файлу даних та отримання даних. Чи можна це зробити? Так, але чому? Це не те, що ваша програма ВІДМІНЮЄ.

Я особисто вважаю, що все, що ви згадали, поза стороною збережених процедур належить до програми. Якщо ви знаєте, що ваша архітектура - X, скористайтеся перевагами X, вручну завантажте на сервер БД, коли це доречно, тощо ... Якщо це може бути X або Y (або Z), тоді ваша програма повинна бути агностичною, якщо ви не намагаючись створити безпеку роботи, переконавшись, що вам, можливо, доведеться рефакторингувати додаток :). Я думаю, що трохи лінощів у поєднанні із зручністю можуть мати до цього щось спільне. Я знаю, що волію робити це на C #, аніж SQL, якщо зможу. . . мої навички C # просто кращі.

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

Коротка відповідь: Багато з цих функцій не є практичними для розробки ОО. Я знаю, що DBA не люблять цього чути, але, це правда. Ці функції гарні для крайніх випадків, і більшість хороших ORM, таких як N / Hibernate, дозволяють надавати SQL для цих крайніх випадків.

Коли справа стосується переважно делегування до CRUD:

Довга відповідь: Я думаю, що СУБД переживає зрілі болі, і знаходить своє місце у світі. Правда: ООП старший за СУБД. ООП лише виходить із наростаючих болів і дозрівання. Я думаю, що SQL як мова є дуже зрілим, але ідея того, з чим повинна керувати СУБД, лише налагоджується. СУБД була власником бізнес-логіки для більшості веб-програм, поки не з'явилися Java та C #. Я думаю, ми зараз тільки починаємо відчувати цю корекцію.

Враховуючи це, я не думаю, що будь-який дизайнер ORM збирається сказати вам, що якість операторів sql, поданих до RDBMS, не має значення.

Що стосується не-CRUD, у мене тут немає відповіді. Більшість магазинів, про які я знаю, як і раніше використовують БД для ETL / тощо ...

Немає достатньої кількості розробників, які знають усі ці функції на рівні, який насправді міг би відрізнятись від звичайного програміста «середнього рівня», коли мова йде про впровадження тієї самої логіки в БД або середній рівень. Можливо, одинокі люди, які справді мають глибокі знання про ці особливості, є DBA. А ті зосереджені на інших проблемах, крім розвитку. Є більше "звичайних" розробників, ніж DBA. Тож знайти дуже потрібних людей для своєї команди було б дуже складно і дорого.

Інший момент полягає в тому, що ви, як правило, збираєте лише поглиблені знання про одну систему баз даних, а не про всі з них. Отже, ви можете мати експертів з SQL Server або Oracle, але не обох. Це призводить (до певної міри) до вузьких областей застосування, де враховується висока спеціалізація. Тоді ринок таких додатків не такий великий, навіть якщо він є.

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

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

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

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

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

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

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

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

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

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

• Ви не знаєте, яку версію програмного забезпечення для баз даних буде виконувати клієнт.
• Клієнти можуть не бажати оновлювати програмне забезпечення бази даних, коли ви цього захочете, через ліцензійні витрати або там, що стосується ІТ-політики.
• Навіть такі основні функції, як матеріалізовані подання, є лише в деяких «виданнях» програмного забезпечення для баз даних, менші клієнти часто не готові платити за високоякісну версію бази даних.
• Рано чи пізно хтось із продавців погодиться використовувати ваше програмне забезпечення із СУБД іншого постачальника.
• Вибір між написанням логіки один раз на середньому рівні або принаймні PL-SQL та TSQL у базі даних - це простий вибір!
• Будь-які зміни в базі даних (нові збережені процедури, оновлені подання тощо) потребуватимуть прав адміністратора БД; це може бути набагато складніше на деяких сайтах клієнтів, ніж просто оновлювати програмне забезпечення.
• Написати сценарій для оновлення бази даних завжди складніше, ніж встановити нову версію dll програми. (Більшість систем збірки сьогодні видають файли MSI як частину кожної збірки)
• Скласти модульний тестовий код у базі даних, а не середній рівень.
• Важче налагодити збережені procs, ніж C #.
• Те, що це працює у вашій базі даних, не означає, що буде працювати в базі даних клієнта, СУБД має занадто багато комутаторів, які змінюють їх роботу - клієнти завжди прагнуть встановлювати їх по-різному.

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