Какие другие языки, отличные от SQL, в настоящее время используются для манипулирования базами данных? [Дубликат]

Проблемы с SQL побудили меня подготовить черновик запросов, указанный SMEQL , в репозитории хранилища ссылок в Portland wiki . Комментарии Добро пожаловать. Он заимствует идеи функционального программирования и экспериментального языка IBM Business System 12. (Я изначально называл его TQL, но позже нашел это имя.)

SQL де-факто.

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

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

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

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

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

Если вы хотите увидеть тип базы данных совершенно другого мышления, взгляните на CouchDB

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

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

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

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

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

Майкл Стоунбрейкер описывает это в . «NoSQL» обсуждает ничего делать с SQL .

Общее движение в эти дни - NoSQL; обычно эти технологии:

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

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

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

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

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