SQL（语言）的替代品是什么？[关闭]

我偶尔会听到一些有关SQL如何烂透的东西，但这不是一种好语言，但我从未真正听到过很多有关它的替代方法的信息。那么，还有其他具有相同目的（数据库访问）的优秀语言，又有什么比SQL更好的语言呢？有没有使用这种替代语言的优秀数据库？

编辑：我熟悉SQL并一直使用它。我对此没有问题，我只是对可能存在的任何替代方案以及人们为什么更喜欢它们感兴趣。

我也不是在寻找替代类型的数据库（NoSQL运动），而是以不同的方式访问数据库。

我当然同意，无论是从自动生成SQL的角度来看还是从解析SQL的角度来看，SQL的语法都难以使用，如果我们为满足需求而设计SQL，这不是我们今天要编写的语言风格。今天就可以了。我认为，如果今天设计语言的话，我们不会找到太多不同的关键字，我怀疑连接语法会有所不同，像GROUP_CONCAT这样的函数将具有更常规的语法，而不是在括号中间插入更多关键字来控制其行为...如果我们今天重新设计了该语言，则希望/期望在SQL中创建您自己希望/希望看到的不一致和冗余的洗衣清单。

对于关系数据库而言，SQL没有其他选择（即SQL作为协议），但是在应用程序中编写SQL的选择有很多。这些替代方案已以与关系数据库一起使用的前端形式实现。前端的一些示例包括：

• SchemeQL和CLSQL，由于其具有Lisp的特性，可能是最灵活的，但与其他前端相比，它们看起来更像SQL。
• LINQ（在.Net中）
• ScalaQL和ScalaQuery（在Scala中）
• SqlStatement，ActiveRecord和其他Ruby中的代码，
• 哈斯克尔数据库
• ...其他许多语言都在继续列出。

我认为今天的基本主题是，我们不是使用一种新的查询语言来代替SQL，而是创建特定于语言的前端，以将SQL隐藏在常规的日常编程语言中，并将SQL作为与关系型对话的协议数据库。

看看这个清单。

休眠查询语言可能是最常见的。Hibernate的优点是对象非常容易（几乎自动）映射到关系数据库，并且开发人员不必花很多时间进行数据库设计。请访问Hibernate网站以获取更多信息。我相信其他人也会喜欢其他有趣的查询语言...

当然，有很多NoSQL内容，但是您特别提到对这些内容不感兴趣。

“我偶尔会听到有关SQL如何糟糕的事情，这不是一种好语言”

SQL已经有30多年的历史了。关于“哪些功能使某种东西成为一种'好的'语言，而哪些使它成为一种'不好的”语言的见解比SQL本身发展得更快。

另外，SQL不是一种符合当前“关系型所必需的”标准的语言，因此，SQL并不是要引导的关系型语言。

“但是我从来没有真正听到过很多关于它的替代品的信息。”

我邀请您考虑一下您尝试只在错误的地方（即，商业DBMS行业）收听的可能性。

“那么，还有其他具有相同目的（数据库访问）的优秀语言，又是什么使其比SQL更好呢？”

Date＆Darwen在其“第三宣言”中描述了现代数据操作语言必须符合的功能，其最新版本已在其“数据库，类型和关系模型”一书中进行了介绍。

“有没有好的数据库使用这种替代语言？”

如果用“好”来表示“工业强度”，则否。最接近的东西可能是Dataphor。

Rel项目提供了在“数据库，类型和关系模型”中定义的Tutorial D语言的实现，但是Rel当前的主要目标本质上是教育性的。

我的SIRA_PRISE项目提供了“真正的关系”数据管理的实现，但是我也犹豫是否将其标记为“一种语言的实现”。

当然，您可能还会像一些人建议的那样研究一些非关系性内容，但是我个人认为非关系性数据管理是数十年来的技术衰退。那不值得考虑。

哦，顺便说一句，用于管理数据库的软件系统不是“数据库”，而是“数据库管理系统”，简称“ DBMS”。就像照片与照相机不一样，如果您正在讨论照相机，并且想避免混淆，那么应该使用正确的词“照相机”而不是“照片”。

也许您在想批评C. Date和他的朋友已经反对现有的关系数据库和SQL。他们说系统和语言不是100％相关的，应该是。我真的没有在这里看到任何真正的问题。据我所知，只要您掌握使用SQL的方式，就可以拥有100％的关系系统。

我个人经常遇到的问题是，SQL缺乏表达能力，而这种能力是从其理论基础（关系代数）继承而来的。一个问题是缺乏对域顺序使用的支持，使用日期，时间戳等标记的数据时会遇到这种问题。我曾经尝试在充满时间戳的数据库上完全用纯SQL编写报表应用程序，但这是不可行的。另一个是缺少对路径遍历的支持：我的大多数数据看起来像有向图，我需要遍历路径，而SQL无法做到这一点。（它缺少“传递闭包”。SQL-1999可以使用“递归子查询”来实现，但是我还没有在实际使用中看到它们。还有各种使SQL应对的技巧，但是它们很丑陋。）这些问题是顺便说一下，Date的一些著作也对此进行了讨论。

最近，我指着.QL似乎很好地解决了传递闭包问题，但我不知道它是否可以解决有序域的问题。

直接回答：我认为那里没有任何竞争者。DBase及其模仿者（Foxpro，Codebase等）曾经是竞争者，但我认为他们基本上输掉了数据库查询语言之战。还有许多其他具有自己的查询语言的数据库产品，例如Progress和Paradox，以及我使用过的其他一些产品，它们的名字我都不记得了，而且肯定还有更多我从未听说过的名字。但我认为，没有其他竞争者能接近获得不小的市场份额。

作为数据库格式和查询语言之间存在差异的简单证明，我使用的DBase的最新版本（很多年前）提供了“传统的” DBase查询语言和SQL，两者都可以使用。访问相同的数据。

旁白：我不会说SQL很烂，但是它有很多缺陷。凭借多年积累的经验和我们的后见之明，我相信人们可以设计出一种更好的查询语言。但是，创建一种更好的查询语言并说服人们使用它是两件截然不同的事情。说服人们值得学习的麻烦会更好吗？人们已经投入了很多年的时间来学习如何有效地使用SQL。即使您的新语言更易于使用，也肯定会有学习上的弯路。以及如何将现有系统从SQL迁移到新语言？等等，当然可以做到，就像C ++，C＃和Java在很大程度上推翻了COBOL和FORTRAN一样。但是要取得成功，需要结合技术优势和良好的市场营销。

尽管如此，我还是会在有人批评它时急于捍卫SQL的人中感到轻笑，他们坚持认为您对SQL的任何问题都必须是您自己对SQL的无能为力，而不是SQL的任何错误，您一定不要冷静下来，深吸一口气：我们侮辱的是计算机语言，而不是您的母亲。

看看 LINQ to SQL ...

几个月前进行了尝试，再也没有回头...。

早在1980年代，ObjectStore就提供了透明的对象访问。除了没有所有额外的泄漏抽象层之外，它有点像RDBMS加上ORM：它直接将对象存储在数据库中。

因此，这种选择实际上是“完全没有语言”，或者也许是“您已经在使用的语言”。您将编写C ++代码并创建或遍历对象，就好像它们是本机对象一样，数据库将根据需要处理所有事情。有点像ActiveRecord，但实际上效果和ActiveRecord营销闪电战一样好。:-)

（当然，它没有甲骨文的营销能力，也没有MySQL的零成本，所以每个人都忽略了它。现在我们尝试用RDBMS和ORM复制它，有些人试图说表实际上存储对象很有意义，并且编写巨大的XML文件来告诉您的计算机如何将对象映射到表是某种合理的解决方案。）

这些天的普遍运动是NoSQL。通常，这些技术是：

• 将数据存储为键/值对的分布式“哈希表”
• 面向文档的数据库

我个人认为SQL只要符合您的需求就没有错。SQL具有表现力，非常适合处理结构化数据。

我认为您可能对Dataphor感兴趣，它是一个开放源代码的关系开发环境，具有自己的数据库服务器（说D），并且具有从其查询语言派生用户界面的能力。

另外，看来 Ingres仍然支持QUEL，并且它是开源的。

SQL在其设计的领域（相互关联的数据表）上运行良好。这通常在传统业务数据处理中找到。尝试持久存储复杂的对象网络时，SQL不能很好地工作。

如果您需要存储和处理相对传统的数据，请使用一些基于SQL的DBMS。

回应您的编辑：

如果您正在寻找SQL DML的替代方法以从关系数据存储中检索数据，那么我从来没有听说过SQL的任何替代方法。

我认为，SQL所带来的冲击与该语言相比并没有太多与该语言所基于的基础数据存储原理相反。人们经常将语言SQL与建立RDBMS的关系数据模型混淆。

关系数据库不是唯一的数据库。我应该说一个关于对象数据库的词，因为我在其他人的回应中没有看到它。我在Zope python框架上有一些经验，该框架使用ZODB进行对象持久性而不是RDBMS（嗯，从理论上讲，可以用zope内的另一个数据库替换ZODB，但是上次我检查不成功时，它可以工作）对此并不乐观）。

ZODB的思维方式实际上是不同的，更像是对象编程，它恰好是持久的。

ORM可被视为一种语言

从某种意义上说，我相信对象数据库模型就是ORM的目的：通过通常的对象模型访问持久性数据。它是一种语言，正在获得一定的市场份额，但是目前我们不将其视为一种语言，而是一种抽象层。但是，我认为在对象数据库上使用ORM比在SQL上使用ORM效率要高得多（换句话说，我碰巧使用某些SQL数据库来吸收ORM的性能）。

SQL的实现方式很多（SQL Server，mysql，Oracle等），但是就设计成用于关系数据存储和检索的通用语言而言，没有其他语言可以达到相同的目的。

有诸如db4o之类的对象数据库，也有类似的所谓noSQL数据库，它们几乎引用了任何不依赖SQL的数据存储机制，但是大多数常见的开源产品（如Cassandra）松散地基于Google的Bigtable概念。

还有许多特殊用途的数据库产品，例如CDF，但您可能不必担心这些-如果需要，您就会知道。

这些都不等同于SQL。

这并不意味着它们是“更好”或“更差”的-它们只是不一样。丹尼斯·福布斯（Dennis Forbes）最近写了一篇很棒的文章，打破了许多针对SQL的奇怪说法。他坚持（我同意），这些抱怨主要来自于人们和商店，他们最初是为该工作选择了错误的工具，或者没有正确使用他们的SQL DBMS（当我这样做时，我什至都不感到惊讶。查看另一个SQL数据库，其中每个列都是一个，varchar(50)并且在任何地方都没有一个索引或键。

如果您正在实施另一个社交网站，而又不太关心ACID原则，则一定要开始研究db4o之类的产品。但是，如果您正在开发关键任务业务系统，我强烈建议您在加入“ SQL Sucks”合唱之前三思。首先进行研究，找出各种产品可以支持和不支持的功能。

编辑-我正忙于写答案，几分钟后才收到问题更新。话虽这么说，SQL本质上与DBMS本身密不可分。如果运行SQL数据库产品，则可以使用SQL句点来访问它。

也许您正在寻找语法上的抽象；Linq to SQL，实体框架，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的问题促使我在Portland Pattern Repository Wiki上编写一种名为SMEQL的查询语言草案。欢迎评论。它借鉴了函数式编程和IBM实验性的Business System 12语言的思想。（我最初将其称为TQL，但后来发现使用了该名称。）

在.NET世界中，尽管它仍然具有SQL风格的感觉，但是LINQ-to-SQL将使您能够很好地结合使用SQL和内存中的.NET处理数据。它也简化了许多真正没人想做的底层数据管道。

如果要查看完全不同的数据库类型，请查看CouchDB。“更好”显然是一个相对要求，这种非关系数据库是“更好”的，但仅在某些情况下才是。

SQL 语言非常强大，并且关系数据库管理系统已经并且仍然取得了巨大的成功。但是有一类应用程序需要非常高的可伸缩性和可用性，但不一定需要高度的数据一致性（最终一致性才是最重要的）。通过放宽对完全符合ACID的事务的需求，各种系统都比RDBMS获得更好的性能和扩展性。这些已被命名为“ NoSQL”，但是正如其他人指出的那样，这是一个错误的称呼：也许应该将它们称为NoACID数据库。

迈克尔·斯通布雷克（Michael Stonebraker）在“ NoSQL”讨论中与SQL无关。