Что хорошие альтернативы к SQL (язык)? [закрытый]

SQL язык очень мощный, и системы управления реляционными базами данных были и остаются огромным успехом. Но есть класс приложений, который требует очень высокой масштабируемости и доступности, но не обязательно высокой степени согласованности данных (конечная согласованность - вот что важно). Различные системы получают лучшую производительность и масштабируемость, чем РСУБД, за счет уменьшения потребности в транзакциях, полностью совместимых с ACID. Они были названы «NoSQL», но, как отмечают другие, это неправильное название: возможно, их следует называть базами данных NoACID.

Майкл Стоунбрейкер рассказывает об этом в . Обсуждение "NoSQL" не имеет ничего общего с SQL .

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

Если вы хотите увидеть базу данных совершенно другого типа мышления, взгляните на CouchDB . «Лучше», очевидно, является относительным требованием, и такая база данных, не связанная с отношениями, считается «Лучше», но только в определенных сценариях.

SQL де-факто.

Фреймворки, которые пытаются защитить разработчиков от этого, в конечном итоге создали свой собственный язык (на ум приходит Hibernate HQL).

SQL довольно хорошо решает проблему. Выучить не сложнее, чем язык программирования высокого уровня. Если вы уже знаете функциональный язык, освоить SQL не составит труда.

Учитывая, что ведущие поставщики баз данных, предоставляющие современные базы данных (Oracle и SQL Server), поддерживают SQL, и вложили годы в механизмы оптимизации и т. Д., А также все ведущее программное обеспечение для моделирования данных и программное обеспечение для управления изменениями на SQL, я бы сказал это самая безопасная ставка.

Кроме того, база данных - это не только запросы. Есть масштабируемость, резервное копирование и восстановление, интеллектуальный анализ данных. Крупные производители поддерживают множество вещей, которые даже новые механизмы "кэширования" даже не принимают во внимание.

SQL прекрасно работает в той области, для которой он был разработан - взаимосвязанные таблицы данных. Это обычно встречается в традиционной обработке бизнес-данных. SQL не так хорошо работает при попытке сохранить сложную сеть объектов.

Если вам нужно хранить и обрабатывать относительно традиционные данные, используйте СУБД на базе SQL.

В ответ на вашу правку:

Если вы ищете альтернативы SQL DML для извлечения данных из реляционных хранилищ данных, то я никогда не слышал о какой-либо серьезной альтернативе SQL.

Нарекания в адрес SQL, как мне кажется, направлены не столько против языка, сколько против базовых принципов хранения данных, на которых основан язык. Люди часто путают язык SQL с реляционной моделью данных, на которой построены РСУБД.

Думаю, вам будет интересно взглянуть на Dataphor , который представляет собой реляционную среду разработки с открытым исходным кодом и собственным сервером базы данных (который говорит на D), и возможность создавать пользовательские интерфейсы на основе своего языка запросов.

Кроме того, похоже, что Ingres по-прежнему поддерживает QUEL, и это открытый исходный код.

Еще в 1980-х годах ObjectStore предоставлял прозрачный доступ к объектам. Это было что-то вроде СУБД плюс ORM, за исключением того, что без всех этих дополнительных просочившихся уровней абстракции: объекты хранились непосредственно в базе данных.

Таким образом, эта альтернатива была действительно «без языка» или, возможно, «языком, который вы уже используете». Вы бы написали код C ++ и создавали или просматривали объекты, как если бы они были собственными объектами, а база данных позаботилась обо всем по мере необходимости. Вроде как ActiveRecord, но на самом деле он работал так же хорошо, как утверждают маркетинговые блицы ActiveRecord. : -)

(Конечно, у него не было маркетинговых возможностей Oracle, и у него не было нулевой стоимости MySQL, поэтому все его проигнорировали. И теперь мы пытаемся воспроизвести это с помощью СУБД и ORM, а некоторые люди попробуйте доказать, что таблицы действительно имеют смысл для хранения объектов, и что написание гигантского XML-файла, сообщающего вашему компьютеру, как отображать объекты в таблицы, является в некотором роде разумным решением.)

Взгляните на этот список.

Hibernate Query Language - вероятно, самый распространенный. Преимущество Hibernate в том, что объекты очень легко (почти автоматически) отображаются на реляционную базу данных, и разработчику не нужно тратить много времени на проектирование базы данных. За дополнительной информацией обратитесь к сайту Hibernate. Я уверен, что другие люди расскажут о других интересных языках запросов...

Конечно, существует множество NoSQL, но вы специально упомянули, что они вас не интересуют.

Общее движение в наши дни - это NoSQL; в целом эти технологии следующие:

• Распределенные "хэш-таблицы", которые хранят данные в виде пар ключ/значение
• Документо-ориентированные базы данных

Лично я думаю, что нет ничего плохого в SQL, пока он соответствует вашим потребностям. SQL выразителен и отлично подходит для работы со структурированными данными.

Возможно, вы думаете о критике, которую К. Дэйт и его друзья высказали против существующих реляционных баз данных и SQL; они говорят, что системы и язык не на 100% взаимосвязаны, и должны быть такими. Я действительно не вижу здесь реальной проблемы; Насколько я понимаю, вы можете иметь 100% реляционную систему, если хотите, просто дисциплинируя способ использования SQL.

Лично я постоянно сталкиваюсь с отсутствием выразительной силы, которую SQL унаследовал от своей теоретической основы, реляционной алгебры. Одной из проблем является отсутствие поддержки использования упорядочивания доменов, с которой вы сталкиваетесь, когда работаете с данными, отмеченными датами, отметками времени и т. Д. Однажды я попытался создать приложение для создания отчетов полностью на простом SQL в базе данных, полной временных меток, и это было просто невозможно. Другой - отсутствие поддержки обхода пути: большинство моих данных выглядят как ориентированные графы, в которых мне нужно проходить пути, а SQL не может этого сделать. (В нем отсутствует "транзитивное закрытие". SQL-1999 может делать это с "рекурсивными подзапросами", но я еще не видел их в реальной практике.Существуют также различные уловки, чтобы заставить SQL справляться, но они уродливы.) Эти проблемы, кстати, также обсуждаются в некоторых работах Дейта.

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

«Иногда я слышу кое-что о том, что SQL - отстой, и это плохой язык»

SQL более тридцати лет. Понимание того, «какие функции делают что-то« хорошим »языком, а какие -« плохим », эволюционировало быстрее, чем сам SQL.

Кроме того, SQL не является языком, который соответствует текущим стандартам «того, что нужно для того, чтобы быть реляционным», поэтому SQL просто не является реляционным языком для загрузки.

«но я никогда особо не слышал об альтернативах этому.»

Я предлагаю вам задуматься над возможностью того, что вы пытаетесь услышать только в неправильных местах (то есть исключительно в индустрии коммерческих СУБД).

«Итак, существуют ли другие хорошие языки, которые служат той же цели (доступ к базе данных), и что делает их лучше, чем SQL?»

Дэйт и Дарвен описывают особенности, которым современный язык манипулирования данными должен соответствовать в своем «Третьем манифесте». , последняя версия которого изложена в их книге «Базы данных, типы и реляционная модель».

«Существуют ли хорошие базы данных, использующие этот альтернативный язык?»

Если под «хорошим» вы имеете в виду что-то вроде «промышленного уровня», то нет. Самым близким из доступных, вероятно, будет Dataphor.

Проект Rel предлагает реализацию для языка Tutorial D, определенного в «Базах данных, типах и реляционной модели», но текущая основная цель Rel - иметь образовательный характер.

Мой проект SIRA_PRISE предлагает реализацию для «действительно реляционного» управления данными, но я не решаюсь называть его также «реализацией языка».

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

Да, кстати, программная система, которая используется для управления базами данных, - это не «база данных», а «система управления базами данных», сокращенно «СУБД». Так же, как фотография - это не то же самое, что камера, и если вы обсуждаете камеры и хотите избежать путаницы, тогда вам следует использовать правильное слово «камеры» вместо «фотография».

Существует множество реализаций SQL (SQL Server, mysql, Oracle и т. Д.), Но нет другого языка , который служил бы той же цели в смысле того, чтобы быть язык общего назначения , предназначенный для хранения и поиска реляционных данных .

Есть объектных баз данных , таких как db4o , и есть аналогичные так называемые noSQL базы данных, которые относятся практически к любому механизму хранения данных, не полагается на SQL, но наиболее распространенные продукты с открытым исходным кодом, такие как Cassandra , основаны на концепции Google Bigtable .

Существует также ряд специализированных продуктов баз данных, таких как CDF, но вам, вероятно, не стоит о них беспокоиться - если он вам понадобится, вы узнаете.

Ни один из них не эквивалентен SQL.

Это не значит, что они «лучше» или «хуже» - они просто не одно и то же. Деннис Форбс недавно написал замечательный пост , в котором разбирается ряд странных утверждений, выдвигаемых против SQL. Он утверждает (и я согласен), что эти жалобы в основном исходят от людей и магазинов, которые либо выбрали неправильный инструмент для работы, либо неправильно используют свою СУБД SQL (я даже больше не удивляюсь, когда я см. другую базу данных SQL, где каждый столбец представляет собой varchar (50) и нигде нет ни одного индекса или ключа).

Если вы создаете еще одну социальную сеть и не слишком озабочены принципами ACID , непременно начните изучать такие продукты, как db4o. Однако, если вы разрабатываете критически важную бизнес-систему, я настоятельно рекомендую настоятельно дважды подумать, прежде чем присоединяться к хору «SQL - отстой». Сначала проведите исследование, выясните, какие функции различные продукты могут поддерживать, а какие не могут.

Изменить - я был занят написанием своего ответа и не получил обновления вопроса через несколько минут. При этом SQL по сути неотделим от самой СУБД. Если вы запускаете продукт базы данных SQL, вы обращаетесь к нему с помощью SQL, точка.

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

Я не знаю ни одного полного «языка», который можно было бы использовать поверх базы данных SQL; не считая переключения на другой продукт базы данных, вы в конечном итоге увидите SQL на конвейере.

Прямой ответ: Я не думаю, что есть какой-то серьезный соперник. DBase и ее имитаторы (Foxpro, Codebase и т.д.) какое-то время были соперниками, но я думаю, что они в основном проиграли войну языков запросов к базам данных. Было много других продуктов для баз данных, которые имели свой собственный язык запросов, например Progress и Paradox, а также несколько других, которые я использовал, имена которых я не помню, и, конечно же, многие другие, о которых я никогда не слышал. Но я не думаю, что какой-либо другой претендент даже приблизился к тому, чтобы получить нетривиальную долю рынка.

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

Попутно: я бы не сказал, что SQL - отстой, но у него много недостатков. Я уверен, что, опираясь на многолетний опыт и оглядываясь назад, можно было бы разработать лучший язык запросов. Но создание лучшего языка запросов и убеждение людей использовать его - это две разные вещи. Было бы лучше убедить людей в том, что изучение того стоило. Люди потратили много лет своей жизни на обучение эффективному использованию SQL. Даже если ваш новый язык будет проще в использовании, вам наверняка придется учиться. И как бы вы перенесли существующие системы с SQL на новый язык? И т.п.Конечно, это можно сделать, точно так же, как C ++, C # и Java в значительной степени вытеснили COBOL и FORTRAN. Но для этого требуется сочетание технического превосходства и хорошего маркетинга.

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

Взгляните на LINQ to SQL ...

Попробовал пару месяцев назад и ни разу не оглядывался .. ..

Реляционные базы данных - не единственный вид баз данных. Я должен сказать несколько слов о Object-Databases , поскольку я не видел этого в ответах других. У меня был некоторый опыт работы с фреймворком Python Zope, который использует ZODB для сохранения объектов вместо РСУБД (ну, теоретически можно заменить ZODB другой базой данных в zope, но в последний раз, когда я проверял, мне не удалось это сделать) пусть он работает, поэтому не могу положительно относиться к этому).

Мышление ZODB действительно отличается, больше похоже на объектное программирование, которое оказывается постоянным.

ORM можно рассматривать как своего рода язык

В каком-то смысле я считаю, что модель объектной базы данных - это то, о чем говорит ORM: доступ к постоянным данным через вашу обычную объектную модель. Это своего рода язык, и он завоевывает некоторую долю рынка, но пока мы рассматриваем его не как язык, а как уровень абстракции. Однако я считаю, что было бы намного эффективнее использовать ORM для базы данных объектов, чем для SQL (другими словами, производительность ORM, которые я использовал, используя некоторую базу данных SQL в качестве базовых слоев).