Які хороші альтернативи SQL (мова)? [зачинено]

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

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

Я також не шукаю альтернативних видів баз даних (рух NoSQL), просто різних способів доступу до баз даних.

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

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

• SchemeQL та CLSQL , які, мабуть, найбільш гнучкі, завдяки своїй спадщині Lisp, але вони також виглядають набагато більше, як SQL, ніж інші фронти.
• LINQ (у .Net)
• ScalaQL і ScalaQuery (в Scala)
• SqlStatement , ActiveRecord та багато інших у Ruby,
• HaskellDB
• ... список продовжується для багатьох інших мов.

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

Погляньте на цей список.

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

Звичайно, там багато NoSQL матеріалів, але ви конкретно зазначаєте, що вас це не цікавить.

"Я іноді чую речі про те, як SQL відстій, і це невдала мова"

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

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

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

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

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

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

"Чи є хороші бази даних, які використовують цю альтернативну мову?"

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

Проект Rel пропонує реалізацію мови підручника D, визначеної в "Бази даних, типи та реляційна модель", але поточною основною метою Rel є навчальний характер.

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

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

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

Можливо, ви замислюєтесь над критикою, яку C. Date та його друзі висловили проти існуючих реляційних баз даних та SQL; вони кажуть, що системи та мова не є на 100% відносними, і повинні бути. Я справді не бачу тут жодної реальної проблеми; наскільки я бачу, ви можете мати 100% реляційну систему, якщо хочете, просто дисциплінуючи спосіб використання SQL.

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

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

Пряма відповідь: Я не думаю, що там є серйозний претендент. DBase та його імітатори (Foxpro, Codebase тощо) були деяким претендентом, але я думаю, що вони в основному втратили війну мови запитів бази даних. Було багато інших продуктів баз даних, які мали власну мову запитів, як, наприклад, «Прогрес» та «Парадокс» та кілька інших, яких я використав, чиї імена я не пам’ятаю, і, безсумнівно, ще багато, про які я ніколи не чув. Але я не думаю, що жоден інший претендент навіть не наблизився до отримання нетривіальної частки ринку.

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

Побічна блукання: Я б не сказав, що SQL відстій, але він має багато недоліків. З урахуванням багаторічного досвіду та огляду, який ми маємо зараз, я впевнений, що можна було б розробити кращу мову запитів. Але створення кращої мови запитів та переконання людей використовувати її - це дві дуже різні речі. Чи досить було б переконати людей, що варто навчитися клопоту. Люди вклали багато років свого життя, навчившись ефективно використовувати SQL. Навіть якщо вашою новою мовою буде легше користуватися, напевно буде крива навчання. І як би ви перенесли існуючі системи з SQL на нову мову? І т. Д. Це, звичайно, можна зробити так само, як C ++, C # і Java значною мірою скинули COBOL і FORTRAN. Але для її отримання потрібна комбінація технічної переваги та хорошого маркетингу.

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

Погляньте на LINQ до SQL ...

Спробував це пару місяців тому і ніколи не озирався ...

Ще в 1980-х роках, ObjectStore забезпечив прозорий доступ до об'єктів. Це було схоже на RDBMS плюс ORM, за винятком усіх цих зайвих шарів абстракції: він зберігав об'єкти безпосередньо в базі даних.

Тож ця альтернатива була насправді "зовсім не мовою", або, можливо, "мовою, яку ви вже використовуєте". Ви будете писати код C ++ і створювати або переміщувати об'єкти так, ніби вони були рідними об'єктами, а база даних дбала про все за потребою. Наче подібний ActiveRecord, але він фактично спрацював так само, як і заява щодо маркетингу ActiveRecord. :-)

(Звичайно, у нього не було маркетингової мускулатури Oracle, і у неї не було нульової вартості MySQL, тому всі ігнорували це. А тепер ми намагаємось повторити це з RDBMS та ORM, і деякі люди намагаються стверджувати, що таблиці насправді має сенс для зберігання об'єктів, а написання гігантського XML-файлу, щоб розповісти комп’ютеру, як об’єктировать об’єкти в таблиці, є якимось розумним рішенням.)

Загальний рух в наші дні - NoSQL; загалом ці технології є:

• Поширені "хештелі", які зберігають дані як пари ключів / значень
• Бази даних, орієнтовані на документи

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

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

Крім того, схоже, Ingres все ще підтримує QUEL, і це відкритий код.

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

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

У відповідь на вашу редакцію:

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

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

Реляційні бази даних - не єдиний вид баз даних навколо. Я повинен сказати слово про Object-Databases, оскільки я цього не бачив у відповідях інших. Я мав певний досвід роботи з рамкою Zope python, яка використовує ZODB для стійкості об'єктів замість RDBMS (ну, теоретично це можливо замінити ZODB на іншу базу даних в межах zope, але останній раз, коли я перевірив, мені не вдалося, щоб вона працювала, тому можу не буду позитивно з цього приводу).

Мислення ZODB насправді інше, більше схоже на об'єктне програмування, яке, можливо, буде стійким.

ORM можна розглядати як своєрідну мову

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

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

Є об'єкт база даних , такі як db4o , і є подібні так звані NoSQL бази дані , які відносяться до будь-якого механізму зберігання даних , які НЕ покладаються на SQL, але найбільш часто з відкритим вихідним кодом продукти , як Кассандра заснованих на вільно від Google Bigtable концепції.

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

Жодне з них не еквівалентне SQL.

Це не означає, що вони "кращі" або "гірші" - вони просто не однакові. Нещодавно Денніс Форбс написав чудовий пост, розбивши ряд дивних претензій, що випливають із SQL. Він стверджує (і я згоден), що ці скарги в основному виникають від людей і магазинів, які або вибрали неправильний інструмент для роботи в першу чергу, або не використовують належним чином SQL СУБД (я навіть не здивований, коли я перегляньте іншу базу даних SQL, де кожен стовпець є varchar(50)а ніде немає жодного індексу чи ключа).

Якщо ви впроваджуєте ще один веб-сайт у соціальних мережах і не надто переймаєтесь принципами ACID , усіма силами почніть вивчати такі продукти, як db4o. Якщо ви розробляєте критичну для місії бізнес-систему, настійно рекомендую подумати двічі перед тим, як приєднатися до хору "SQL sucks". Зробіть спочатку дослідження, з’ясуйте, які особливості різних продуктів можуть, а що не можуть підтримувати.

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

Можливо, ви шукаєте абстракції над синтаксисом; Linq до SQL, Entity Framework, Hibernate / NHibernate, SubSonic та безліч інших інструментів ORM надають власний SQL-подібний синтаксис, що не зовсім SQL. Усі ці "складання" в SQL. Якщо ви запускаєте SQL Server, ви також можете написати CLR функції / процедури / тригери, що дозволяє писати код на будь-якій мові .NET, яка буде працювати всередині бази даних; однак це насправді не замінює SQL, а більше розширення до нього.

Я не знаю жодної повної "мови", якою ви зможете нанести вершину бази даних SQL; окрім переходу на інший продукт бази даних, ви врешті-решт побачите SQL у трубі.

SQL фактично є.

Рамки, які намагаються захистити від нього розробників, врешті-решт створили свою власну специфічну мову (на розум приходить Hibernate HQL).

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

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

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

Проблеми з SQL мотивували мене готувати проект запиту під назвою SMEQL на вікі-сховищі Portland Pattern Repository . Коментарі Ласкаво просимо. Він запозичує ідеї з функціонального програмування та експериментальної мови IBM Business System 12. (Я спочатку називав його TQL, але пізніше знайшов це ім'я.)

У світі .NET, хоча він досі має відчуття SQL до нього, LINQ-to-SQL дозволить вам добре поєднати SQL і .NET-обробку ваших даних. Це також спрощує багато сантехнічних даних нижчого рівня, що ніхто насправді не хоче робити.

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

SQL мова є дуже потужною, і реляційні системи управління базами даних мали і залишаються величезним успіхом. Але є клас додатків, який вимагає дуже високої масштабованості та доступності, але не обов'язково високий ступінь узгодженості даних (важлива можлива узгодженість). Різноманітні системи отримують кращі показники та масштабування, ніж RDBMS, послаблюючи потребу в повному обсязі транзакцій, сумісних з ACID. Вони були названі "NoSQL", але, як зазначають інші, це неправильне значення: можливо, їх слід називати базами даних NoACID.

Майкл Стоунбрейкер висвітлює це в дискусії "NoSQL", що не має нічого спільного з SQL .