Чому немає любові до SQL? [зачинено]

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

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

Що робить SQL таким жахливим і чому цінні шари абстракції баз даних?

Частково це суб'єктивно. Отже, це моя думка:

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

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

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

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

Але це правда - можливих альтернатив немає. Таким чином, ми всі будемо використовувати SQL протягом наступних кількох років.

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

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

SQL - це чудово. Шари абстракції над нею роблять ще більше!

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

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

SQL отримує пошкодження з кількох джерел:

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

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

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

Якби вони серйозно ставились до критики самого SQL, вони б підтримали зусилля на зразок Підручника D та Dataphor.

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

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

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

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

Я не скажу, що це жахливо. Це не підходить для деяких завдань. Наприклад: ви не можете написати хороший процедурний код із SQL. Колись мене змусили працювати з набором маніпуляцій із SQL. На це мені знадобилися цілі вихідні, щоб зрозуміти це.

SQL був розроблений для реляційної алгебри - саме там її слід використовувати.

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

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

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

... причина, з якої я щойно описаний вище.

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

За визначенням, у шарах бази даних нічого не є SQL.

Що робить SQLтак жахливим і чому цінні шари абстракції баз даних?

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

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

На практиці існує багато способів сформулювати правильний запит (тобто запит, який повертає правильні результати).

Оптимізатори здатні створити замок Лего з деяких заздалегідь заданих алгоритмів (так, їх багато), але вони просто не можуть створити нові алгоритми. Все ще потрібно SQLрозробнику, щоб допомогти їм.

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

І як ми всі знаємо, коли комп’ютерна програма не відповідає очікуванням людей, це стає виною саме програма, а не очікування.

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

Хоча було б добре, якби постачальники надавали доступ низького рівня до функцій на кшталт "отримати діапазон індексу", "отримати рядок rowid" тощо, як Cкомпілятори дозволяють вбудовувати збірку прямо на мову.

Я нещодавно написав статтю про це у своєму блозі:

• Подвійне мислення в SQL

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

Я розглядаю SQL як надзвичайно ефективну мову, яка не має повторного використання коду або ремонту / рефакторингу як пріоритетних.

Тож блискавична обробка - це пріоритет. І це прийнятно. Ви просто повинні бути обізнані про компроміси, які для мене значні.

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

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

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

2. Багато програмістів просто погано користуються SQL. З будь-якої причини, велика кількість розробників (особливо веб-розробників), здається, дуже і дуже погано використовує SQL або RDBMS. Вони розглядають базу даних (і SQL за допомогою розширення) як хмурий маленький посередник, через який вони мають пройти, щоб дістатися до даних. Це призводить до вкрай погано продуманих баз даних без індексів, таблиць, складених вгорі таблиць із сумнівними способами, і дуже погано написаних запитів. Або ще гірше, вони намагаються бути надто загальними (Експертна система, хтось?) І не можуть обґрунтовано співвідносити дані в будь-якому значущому плані.

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

SQL відмінно підходить для виконання певних завдань, особливо для маніпулювання та отримання наборів даних.

Однак у SQL бракує (або частково реалізується) декілька важливих інструментів управління змінами та складністю:

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

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

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

• Модульність та версія

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

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

SQL базується на теорії задань, тоді як більшість мов високого рівня є об'єктно орієнтованими в наші дні. Об'єктні програмісти, як правило, люблять думати над об'єктами, і їм доводиться робити ментальний зсув, щоб використовувати інструменти на основі встановлених програм для зберігання своїх об'єктів. Як правило, набагато природніше (для програміста OO) просто вирізати код мовою, яку вони обрали, і зробити щось на зразок object.save або object.delete в коді програми, замість того, щоб писати запити sql і викликати базу даних для досягнення той же результат.

Звичайно, інколи для складних речей SQL простіший у використанні та ефективніший, тому добре мати ручку обох типів технології.

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

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

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

Чув багато останнім часом? Сподіваюся, ви не плутаєте це з рухом NoSql. Наскільки мені відомо, що це в основному купа людей, які використовують NoSql для веб-додатків із високою масштабованістю і, здається, забули, що SQL є ефективним інструментом у сценарії, що не стосується веб-додатків із високою масштабованістю.

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

Для досвідченого програміста SQL погані сторони

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

Для інших причини такі

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

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

[оновлення 26.06.10] Нещодавно я працював з модулем Django ORM . Це єдина гідна рамка SQL, яку я бачив. І це робить багато з роботою з речами. Однак складні агрегати трохи складніше.

SQL не є страшною мовою, іноді просто не дуже добре грає з іншими.

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

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

Інша причина, чому SQL ненавидять, - це реляційні бази даних.

CAP Теорема стає популярним:

Які цілі ви можете отримати від системи спільних даних?

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

У теоремі зазначається, що завжди можна мати лише два з трьох властивостей CAP одночасно

Адреса реляційної бази даних Сильна консистенція та толерантність до розділів.

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

Якщо реляційна база даних відхилена, SQL також відхилений.

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

Моя теорія полягає в тому, що SQL була винайдена купою синіх лижників-башток із слонової кістки. Вся непроцедурна структура. Звучить чудово: скажи мені, що ти хочеш, а не як ти хочеш це зробити. Але на практиці часто простіше просто робити кроки. Часто це здається спробою дати інструкції з технічного обслуговування автомобіля, описуючи, як повинен працювати автомобіль, коли закінчите. Так, ви можете сказати: "Я хочу, щоб машина знову отримала 30 миль на галон, і бігала з таким гудінням, як цей ... хммм ... і т. Д." Але хіба не було б легше всім просто скажіть: «Замінити свічки запалювання»? І навіть коли ви зрозумієте, як висловити складний запит у непроцедурних умовах, двигун бази даних часто складається з дуже неефективним планом виконання, щоб потрапити туди.

І поводження з нулями зводить мене з розуму! Так, теоретично це повинно було звучати чудово, коли хтось сказав: "Ей, якщо null означає невідоме, то додавання невідомого значення до відомого значення має дати невідоме значення. Зрештою, за визначенням ми не маємо поняття, що таке невідоме значення" . " Теоретично абсолютно вірно. На практиці, якщо у нас є 10 000 клієнтів і ми точно знаємо, скільки грошей заборгували нам 9 999, але виникає питання щодо суми заборгованості за останній, а керівництво каже: "Яка загальна дебіторська заборгованість?", Так, математично правильно відповідь "я не знаю". Але практична відповідь - "ми обчислюємо $ 4,327,287.42, але один рахунок знаходиться під питанням, тому число не є точним". Я впевнений, що керівництво швидше наблизиться, якби не певна кількість, ніж порожній погляд.

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

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

• Синтаксис SQL не є ортогональним; наприклад, select, insert, update,і deleteвсі твердження мають абсолютно різну синтаксичну структуру.

Я погоджуюся з вашими питаннями, але, щоб відповісти на ваше запитання, одне, що робить SQL таким "жахливим", - це відсутність повної стандартизації T-SQL між постачальниками баз даних (Sql Server, Oracle тощо), що робить SQL-кодом малоймовірним. повністю портативний. Шари абстрагування бази даних вирішують цю проблему, хоча і з вартістю продуктивності (іноді дуже суворою).

Життя з чистим SQL може насправді бути пеклам обслуговування. Для мене найбільшою перевагою ORM є можливість безпечного рефакторного коду без набридливих процедур "рефакторингу БД". Є хороші рамки тестування підрозділів та інструменти рефакторингу для мов OO, але мені ще належить побачити, наприклад, аналог Resharper для SQL.

Проте всі DAL мають SQL за лаштунками, і все одно вам потрібно це знати, щоб зрозуміти, що відбувається з вашою базою даних, але щоденна робота з хорошим шаром абстракції стає простішою.

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

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

Швидко напишіть мені SQL, щоб застосувати пакунок набору даних, який працює в MySQL, Oracle, MSSQL, PostgreSQL та DB2.

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

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

• це синтаксис - шрапнель коболів, тут застосовується вся критика коболів (меншою мірою, щоб бути справедливою). Намагаючись бути природною мовою, як насправді, не намагаючись інтерпретувати природну мову, створює синтаксис арбітражної ситуації (чи це ВИДАЛЕННЯ ТАБЛИЦІ, ПІДГОТОВКА, ОНОВЛЮВАННЯ ТАБЛИЦІ, ОНОВЛЕННЯ або ОНОВЛЕННЯ В, ЗВІДКУЙТЕСЬ або ВИДАЛИТИ ЗІ ...) та синтаксичні жахливості на зразок SELECT (скільки сторінок робить це заповнити?)
• семантика також глибоко хибна, Дата пояснює це досить докладно, але буде достатньо відзначити, що тризначна булева логіка насправді не відповідає реляційній алгебрі, де ряд може бути або не бути частиною таблиці
• наявність мови програмування в якості основного (і часто тільки) інтерфейсу до баз даних виявилося дійсно поганим вибором, і це створило нову категорію вад безпеки

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

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

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

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

Хоча SQL справді виконує роботу, у неї, безумовно, є проблеми ...

• вона намагається одночасно бути високим і низьким рівнем абстракції , і це ... дивно. Можливо, це мали бути два чи більше стандартів на різних рівнях.
• це величезний збій як стандарт . Багато речей піде не так, коли стандарт або утримується у всьому, вимагає занадто багато реалізацій, запитує занадто мало, або чомусь не досягає частково соціальної мети мотивувати постачальників та впроваджувачів для отримання суворо відповідних сумісних повноцінних реалізацій. Ви, звичайно, не можете сказати, що SQL зробив щось із цього. Подивіться на деякі інші стандарти та зауважте, що успіх чи невдача стандарту є явно фактором корисної співпраці:
  • RS-232 ( Погано , недостатньо майже вказано. Навіть, який контактний контакт передається та який контактний PIN-код отримується, необов’язково. Ви можете виконати, але все одно нічого не досягнете. Шанс успішного інтеропу: дійсно низький, поки IBM PC не зробив фактично корисний стандарт .)
  • IEEE 754-1985 з плаваючою точкою ( погано , надмірно: ні один суперкомп'ютер, ні наукова робоча станція, ні мікропроцесор RISC ніколи не прийняли його, хоча врешті-решт через 20 років ми змогли його гарненько реалізувати у HW. Принаймні, світ врешті-решт перетворився на нього.)
  • C89, C99, PCI, USB, Java ( Добре , будь то стандартний або специфікаційний, їм вдалося мотивувати суворе дотримання майже всіх, і ця відповідність призвела до успішної взаємодії.)
• його не вдалося обрати для, мабуть, найважливішої бази даних у світі . Хоча це більше, ніж причина, ніж причина, той факт, що Google Bigtable не є SQL і не є реляційним, є своєрідним антидосягненням для SQL.

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

Переваги величезні. Написання тестів навколо коду, використання експресивних класів, сильно набраних наборів даних тощо. Ми використовуємо "DAL" сортів, що є чистою реалізацією DDD за допомогою Generics в C #. Таким чином, у нас є загальні сховища, реалізація одиниці роботи (транзакції на основі коду) та логічне розділення. Ми можемо робити такі речі, як знущатися з наборів даних з невеликими зусиллями і насправді розвиватись перед реалізацією бази даних. Було заздалегідь витрачено на створення такого каркасу, але це дуже приємно ділова логіка знову є зіркою шоу. Зараз ми споживаємо дані як ресурс і обробляємо їх мовою, якою ми користуємось у коді. Додатковою перевагою такого підходу є чітке розмежування, яке він забезпечує. Наприклад, я більше не бачу запит до бази даних на веб-сторінці. Так, цій сторінці потрібні дані. Так, база даних задіяна. Але тепер, куди б я не діставав дані, є одне (і єдине) місце, щоб зайти в код і знайти його. Можливо, це не велика справа щодо менших проектів, але коли у вас є сотні сторінок на сайті або десятки вікон у настільному додатку, ви справді можете оцінити це.

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

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

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