Иногда я слышу о том, что SQL - отстой, и это плохой язык, но я никогда особо не слышал об альтернативах ему. Итак, есть ли другие хорошие языки, которые служат той же цели (доступ к базе данных), и что делает их лучше, чем SQL? Есть ли хорошие базы данных, использующие этот альтернативный язык?
РЕДАКТИРОВАТЬ: Я знаком с SQL и использую его все время. У меня нет проблем с этим, меня просто интересуют любые альтернативы, которые могут существовать, и почему людям они нравятся больше.
Я также не ищу альтернативные типы баз данных (движение NoSQL), а просто разные способы доступа к базам данных.
Ответы:
Я, конечно, согласен с тем, что с синтаксисом SQL сложно работать, как с точки зрения его автоматической генерации, так и с точки зрения его синтаксического анализа, и это не тот стиль языка, который мы бы написали сегодня, если бы мы разрабатывали SQL для требований, которые мы предъявляем. на нем сегодня. Я не думаю, что мы нашли бы так много разнообразных ключевых слов, если бы мы разработали язык сегодня, я подозреваю, что синтаксис соединения был бы другим, такие функции, как
GROUP_CONCATимели бы более регулярный синтаксис, вместо того, чтобы вставлять больше ключевых слов в середине круглых скобок, чтобы контролировать его поведение ... создайте свой собственный обширный список несоответствий и избыточностей в SQL, которые вы хотели бы / ожидали увидеть сглаженными, если бы мы переделали язык сегодня.Нет никаких альтернатив SQL для общения с реляционными базами данных (т.е. SQL как протокол), но есть много альтернатив написанию SQL в ваших приложениях. Эти альтернативы реализованы в виде интерфейсов для работы с реляционными базами данных. Вот некоторые примеры внешнего интерфейса:
Я думаю, что основная тема сегодня заключается в том, что вместо того, чтобы заменять SQL одним новым языком запросов, мы вместо этого создаем интерфейсы для конкретных языков, чтобы скрыть SQL в наших обычных повседневных языках программирования, и рассматриваем SQL как протокол для общения с реляционными базы данных.
источник
Взгляните на этот список.
Hibernate Query Language , вероятно, самый распространенный. Преимущество Hibernate заключается в том, что объекты очень легко (почти автоматически) сопоставляются с реляционной базой данных, и разработчику не нужно тратить много времени на проектирование базы данных. Посетите веб-сайт Hibernate для получения дополнительной информации. Я уверен, что другие присоединятся к другим интересным языкам запросов ...
Конечно, существует множество материалов по NoSQL, но вы специально указываете, что они вам не интересны.
источник
SQL более тридцати лет. Понимание того, «какие функции делают что-то« хорошим »языком, а какие -« плохим », эволюционировало быстрее, чем сам SQL.
Кроме того, SQL не является языком, который соответствует текущим стандартам «того, что нужно для того, чтобы быть реляционным», поэтому SQL просто не является реляционным языком для загрузки.
Я предлагаю вам задуматься о возможности того, что вы пытаетесь услышать только в неправильных местах (то есть исключительно в индустрии коммерческих СУБД).
Дэйт и Дарвен описывают особенности, которым должен соответствовать современный язык обработки данных, в своем «Третьем манифесте», самая последняя версия которого изложена в их книге «Базы данных, типы и реляционная модель».
Если под словом «хорошо» вы имеете в виду что-то вроде «промышленного уровня», то нет. Самым близким из доступных, вероятно, будет Dataphor.
Проект Rel предлагает реализацию языка Tutorial D, определенного в разделе «Базы данных, типы и реляционная модель», но текущая основная цель Rel - иметь образовательный характер.
Мой проект SIRA_PRISE предлагает реализацию для «действительно реляционного» управления данными, но я не решаюсь называть его также «реализацией языка».
И, конечно, вы также можете изучить некоторые нереляционные вещи, как предлагали некоторые, но я лично отвергаю нереляционное управление данными как несколько десятилетий технологического регресса. Не стоит думать, конечно.
Да, кстати, программная система, которая используется для управления базами данных, - это не «база данных», а «система управления базами данных», сокращенно «СУБД». Так же, как фотография - это не то же самое, что фотоаппарат, и если вы обсуждаете фотоаппараты и хотите избежать путаницы, тогда вам следует использовать правильное слово «камеры» вместо «фотография».
источник
Возможно, вы думаете о критике, которую Ч. Дэйт и его друзья высказали в адрес существующих реляционных баз данных и SQL; они говорят, что системы и язык не на 100% взаимосвязаны, и должны быть такими. Я действительно не вижу здесь реальной проблемы; насколько я понимаю, вы можете получить 100% реляционную систему, если хотите, просто дисциплинировав способ использования SQL.
Лично я постоянно сталкиваюсь с отсутствием выразительной силы, которую SQL унаследовал от своей теоретической основы - реляционной алгебры. Одной из проблем является отсутствие поддержки использования упорядочивания доменов, с которой вы сталкиваетесь, когда работаете с данными, отмеченными датами, отметками времени и т. Д. Однажды я попытался создать приложение для создания отчетов полностью на простом SQL в базе данных, полной временных меток, и это было невозможно. Другой - отсутствие поддержки обхода пути: большинство моих данных выглядят как ориентированные графы, в которых мне нужно проходить пути, а SQL не может этого сделать. (В нем отсутствует "транзитивное закрытие". SQL-1999 может делать это с "рекурсивными подзапросами", но я еще не видел их в реальной практике. Существуют также различные приемы, позволяющие справиться с SQL, но они уродливые.) Это проблемы. кстати, также обсуждается в некоторых работах Дэйта.
Недавно меня указали на .QL, который, кажется, хорошо решает проблему транзитивного закрытия, но я не знаю, может ли он решить проблему с упорядоченными доменами.
источник
Прямой ответ: я не думаю, что есть какой-то серьезный соперник. DBase и ее имитаторы (Foxpro, Codebase и т. Д.) Какое-то время были соперниками, но я думаю, что они в основном проиграли войну языков запросов к базам данных. Было много других продуктов для баз данных, имевших собственный язык запросов, таких как Progress и Paradox, а также несколько других, которые я использовал, имена которых я не помню, и, конечно же, многие другие, о которых я никогда не слышал. Но я не думаю, что какой-то другой претендент даже приблизился к получению нетривиальной доли рынка.
В качестве простого доказательства того, что существует разница между форматом базы данных и языком запросов, последняя версия DBase, которую я использовал - много лет назад - предлагала как «традиционный» язык запросов DBase, так и SQL, оба из которых можно было использовать. для доступа к тем же данным.
Попутно: я бы не сказал, что SQL - отстой, но у него много недостатков. Я уверен, что благодаря многолетнему опыту и прошлому, который у нас есть, можно было бы разработать лучший язык запросов. Но создание лучшего языка запросов и убеждение людей использовать его - это две разные вещи. Было бы лучше убедить людей в том, что изучение того стоит. Люди потратили много лет своей жизни на обучение эффективному использованию SQL. Даже если ваш новый язык будет проще в использовании, вам наверняка придется учиться. И как бы вы перенесли существующие системы с SQL на новый язык? И т. Д. Это, конечно, можно сделать, точно так же, как C ++, C # и Java в значительной степени вытеснили COBOL и FORTRAN. Но для этого требуется сочетание технического превосходства и хорошего маркетинга.
Тем не менее, я получаю смешок от людей, которые бросаются защищать SQL каждый раз, когда кто-то его критикует, которые настаивают на том, что любая проблема, которая у вас есть с SQL, должна быть вашей собственной неспособностью использовать его, а не какой-либо ошибкой SQL, что вы просто не должны иметь достигли более высокого уровня образования вещей, необходимого для понимания его совершенства, и т. д. Успокойтесь, сделайте глубокий вдох: мы оскорбляем компьютерный язык, а не вашу мать.
источник
Взгляните на LINQ to SQL ...
Попробовал пару месяцев назад и никогда не оглядывался ....
источник
Еще в 1980-х ObjectStore предоставлял прозрачный доступ к объектам. Это было что-то вроде РСУБД плюс ORM, за исключением того, что не было лишних слоев абстракции с утечкой: объекты хранились непосредственно в базе данных.
Таким образом, эта альтернатива была действительно «без языка» или, возможно, «языком, который вы уже используете». Вы бы написали код C ++ и создавали или просматривали объекты, как если бы они были собственными объектами, а база данных позаботится обо всем по мере необходимости. Вроде как ActiveRecord, но на самом деле он работал так же хорошо, как утверждают маркетинговые блицы ActiveRecord. :-)
(Конечно, у него не было маркетинговых возможностей Oracle, и у него не было нулевой стоимости MySQL, поэтому все игнорировали его. И теперь мы пытаемся воспроизвести это с помощью RDBMS и ORM, и некоторые люди пытаются утверждать, что таблицы на самом деле имеет смысл для хранения объектов, и что написание гигантского XML-файла, сообщающего вашему компьютеру, как отображать объекты в таблицы, в каком-то смысле является разумным решением.)
источник
Я думаю, вам может быть интересно взглянуть на Dataphor , который представляет собой реляционную среду разработки с открытым исходным кодом, со своим собственным сервером базы данных (который говорит на D) и возможностью выводить пользовательские интерфейсы из своего языка запросов.
Кроме того, похоже, что Ingres по- прежнему поддерживает QUEL с открытым исходным кодом.
источник
Общее движение в наши дни - NoSQL; как правило, эти технологии:
Лично я считаю, что в SQL нет ничего плохого, если он соответствует вашим потребностям. SQL выразителен и отлично подходит для работы со структурированными данными.
источник
SQL отлично работает для домена, для которого он был разработан - взаимосвязанных таблиц данных. Обычно это происходит при традиционной обработке бизнес-данных. SQL не так хорошо работает при попытке сохранить сложную сеть объектов.
Если вам нужно хранить и обрабатывать относительно традиционные данные, используйте СУБД на базе SQL.
В ответ на ваше изменение:
Если вы ищете альтернативы SQL DML для извлечения данных из реляционных хранилищ данных, я никогда не слышал о какой-либо серьезной альтернативе SQL.
Я думаю, что удары, которые получает SQL, не столько противоречат языку, сколько основным принципам хранения данных, на которых основан язык. Люди часто путают язык SQL с реляционной моделью данных, на которой построены СУБД.
источник
Реляционные базы данных - не единственный вид баз данных. Я должен сказать несколько слов об объектных базах данных, поскольку я не видел этого в ответах других. У меня был некоторый опыт работы с фреймворком Python Zope, который использует ZODB для сохранения объектов вместо РСУБД (ну, теоретически возможно заменить ZODB другой базой данных в zope, но в последний раз, когда я проверял, мне не удалось заставить его работать, так что могу Я не уверен в этом).
Мышление ZODB действительно иное, больше похоже на объектное программирование, которое может быть постоянным.
ORM можно рассматривать как своего рода язык
В каком-то смысле я считаю, что модель объектной базы данных - это то, о чем ORM: доступ к постоянным данным через вашу обычную объектную модель. Это своего рода язык, и он завоевывает некоторую долю рынка, но пока мы рассматриваем его не как язык, а как уровень абстракции. Однако я считаю, что было бы намного эффективнее использовать ORM над объектной базой данных, чем над SQL (другими словами, производительность ORM, которую я использовал, используя некоторую базу данных SQL в качестве базовых слоев).
источник
Существует множество реализаций SQL (SQL Server, mysql, Oracle и т. Д.), Но нет другого языка, который служил бы той же цели в том смысле, что являлся бы языком общего назначения, предназначенным для реляционного хранения и поиска данных .
Существуют объектные базы данных, такие как db4o , и аналогичные так называемые базы данных noSQL, которые относятся практически к любому механизму хранения данных, который не полагается на SQL, но чаще всего к продуктам с открытым исходным кодом, таким как Cassandra, основанным на концепции Bigtable Google .
Существует также ряд специализированных продуктов для баз данных, таких как 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 на конвейере.
источник
SQL де-факто.
Фреймворки, которые пытаются защитить разработчиков от этого, в конечном итоге создали свой собственный язык (на ум приходит Hibernate HQL).
SQL неплохо решает проблему. Выучить не сложнее, чем язык программирования высокого уровня. Если вы уже знаете функциональный язык, освоить SQL не составит труда.
Учитывая, что ведущие поставщики баз данных, предоставляющие современные базы данных (Oracle и SQL Server), поддерживают SQL и вложили годы в механизмы оптимизации и т. Д., А также все ведущее программное обеспечение для моделирования данных и программное обеспечение для управления изменениями в SQL, я бы сказал, что это самая безопасная ставка.
Кроме того, база данных - это не только запросы. Есть масштабируемость, резервное копирование и восстановление, интеллектуальный анализ данных. Крупные поставщики поддерживают множество вещей, которые даже новые механизмы "кэширования" даже не учитывают.
источник
Проблемы с SQL побудили меня подготовить черновик языка запросов под названием SMEQL в вики Portland Pattern Repository . Комментарии Добро пожаловать. Он заимствует идеи из функционального программирования и экспериментального языка IBM Business System 12. (Первоначально я называл это TQL, но позже выяснил, что это имя было занято.)
источник
В мире .NET, хотя LINQ-to-SQL по-прежнему ощущается в стиле SQL, он позволит вам хорошо сочетать SQL и обработку данных .NET в памяти. Это также упрощает многие операции по передаче данных нижнего уровня, что на самом деле никому не нужно.
Если вы хотите увидеть базу данных совершенно другого типа мышления, взгляните на CouchDB . «Лучше», очевидно, является относительным требованием, и такая база данных, не связанная с отношениями, считается «Лучше», но только в определенных сценариях.
источник
SQL язык является очень мощным, и реляционные системы управления базами данных, были и до сих пор огромный успех. Но есть класс приложений, требующий очень высокой масштабируемости и доступности, но не обязательно высокой степени согласованности данных (конечная согласованность - вот что важно). Различные системы получают лучшую производительность и масштабируемость, чем РСУБД, за счет уменьшения потребности в транзакциях, полностью совместимых с ACID. Они были названы «NoSQL», но, как отмечают другие, это неправильное название: возможно, их следует называть базами данных NoACID.
Майкл Стоунбрейкер рассказывает об этом в «NoSQL». Обсуждение не имеет ничего общего с SQL .
источник