什么是SQL(语言)的好替代方案?[关闭]

我当然同意,无论是从自动生成SQL的角度,还是从解析SQL的角度,SQL的语法都很难使用,而且如果我们为今天的需求设计SQL的话,这不是我们今天要编写的语言风格。我不认为我们会发现这么多不同的关键字,如果我们今天设计的语言,我怀疑连接语法会不同,功能如下 GROUP_CONCAT 会有更规则的语法而不是在括号中间插入更多的关键字来控制它的行为…创建您自己的SQL中的不一致性和冗余列表,如果我们今天重新设计了该语言,您希望/期望看到这些列表被消除。

对于与关系数据库交谈,没有任何SQL的替代方案(即SQL作为协议),但是在应用程序中编写SQL有许多替代方案。这些备选方案以前端的形式实现,用于处理关系数据库。前端的一些示例包括:

• SchemeQL 和 CLSQL 这可能是最灵活的,因为他们的Lisp传统,但他们看起来也比其他前端更像SQL。
• LINQ(in .net)
• ScalaQL 和 ScalaQuery (在斯卡拉)
• SqlStatement , ActiveRecord 还有许多其他的红宝石,
• HaskellDB
• …这个名单上还有很多其他语言。

我认为,今天的基本主题是,我们不是用一种新的查询语言替换SQL,而是创建特定于语言的前端,以在日常编程语言中隐藏SQL,并将SQL视为 协议 用于与关系数据库交谈。

Take a look at this list.

Hibernate Query Language 可能是最常见的。Hibernate的优点是,对象很容易(几乎自动)映射到关系数据库,开发人员不必花费太多时间进行数据库设计。退房 Hibernate website 更多信息。我相信其他人会加入其他有趣的查询语言…

当然,这里有很多nosql的东西,但是你特别提到你对它们不感兴趣。

“我偶尔听到一些关于SQL如何糟糕的事情,这不是一种好的语言。”

SQL已经30多年了。关于“哪些特性使某个东西成为‘好’语言,哪些特性使它成为‘坏’语言”的见解比SQL本身发展得更快。

此外,SQL并不是一种符合“关系需要什么”的当前标准的语言,因此,SQL不是一种要启动的关系语言。

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

我邀请您思考一下,您可能只是在错误的地方(也就是说,专门针对商业DBMS行业)想听。

“那么,其他的好语言是否有同样的用途(数据库访问),是什么使它们比SQL更好?”

日期和达尔文在他们的“第三份宣言”中描述了现代数据操作语言必须符合的特征,最新版本的宣言载于他们的书“数据库、类型和关系模型”。

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

如果说“好”,你的意思是“工业实力”,那么不是。最接近的可能是数据量。

rel项目为“数据库、类型和关系模型”中定义的教程D语言提供了一个实现,但是rel的当前主要目标本质上是教育性的。

我的Sira企业项目为“真正的关系型”数据管理提供了一个实现,但我犹豫要不要将其标记为“语言的实现”。

当然,您也可以研究一些非关系性的东西,正如一些人提出的那样,但是我个人认为非关系性数据管理是几十年的技术回归。这不值得考虑。

哦,顺便说一下,用来管理数据库的软件系统不是“数据库”,而是“数据库管理系统”,简称“DBMS”。就像照片和照相机不一样,如果你在讨论照相机,并且你想避免混淆,那么你应该用恰当的词“照相机”而不是“照片”。

也许你在考虑C.Date和他的朋友们对现有关系数据库和SQL的批评;他们说系统和语言不是100%关系的,应该是。我在这里没有看到任何真正的问题;据我所知,如果您愿意的话,您可以拥有一个100%的关系系统,只是通过控制您使用SQL的方式。

我个人经常遇到的是,缺乏SQL从理论基础(关系代数)继承来的表达能力。一个问题是对域排序的使用缺乏支持,当您使用日期、时间戳等标记的数据时会遇到这种情况。我曾经尝试在一个充满时间戳的数据库上完全用纯SQL来做一个报告应用程序,但这是不可行的。另一个原因是缺乏对路径遍历的支持:我的大多数数据看起来像是需要遍历路径的有向图,而SQL不能这样做。(它缺乏“可传递闭包”。SQL-1999可以用“递归子查询”来实现,但我还没有在实际使用中看到它们。还有各种各样的黑客让SQL能够应付,但它们都很难看。)顺便说一下,这些问题也被一些日期的著作讨论过。

最近我被指 .QL 这似乎很好地解决了可传递闭包问题,但我不知道它是否可以用有序域来解决这个问题。

看一看 LINQ to SQL …

几个月前就试过了,再也没有回头看……

直接回答:我认为没有什么真正的竞争者。DBase及其模仿者(FoxPro、CodeBase等)曾一度是竞争对手,但我认为他们基本上输掉了数据库查询语言之战。有许多其他的数据库产品有自己的查询语言,比如progress和paradox,还有一些我用过的名字我不记得了,当然还有很多我从未听说过的。但我认为没有其他竞争者能在市场上获得不小的份额。

作为数据库格式和查询语言之间存在差异的简单证明,许多年前我使用的数据库的最后一个版本提供了“传统”的数据库查询语言和SQL,这两种语言都可以用于访问相同的数据。

旁白:我不会说SQL很烂,但它有很多缺陷。有了多年的经验和事后诸葛亮,我相信我们可以设计出更好的查询语言。但是,创建一种更好的查询语言,并说服人们使用它,是两个截然不同的事情。能不能更好地让人们相信它值得学习。人们花了很多年的时间学习如何有效地使用SQL。即使你的新语言更容易使用,也肯定会有一条学习曲线。您将如何将现有系统从SQL迁移到新语言?当然,它可以像C++,C语言那样完成,而Java很大程度上推翻了COBOL和FORTRAN。但要实现这一目标,必须结合技术优势和良好的市场营销。

尽管如此,我还是被那些在任何时候批评SQL时都急于为其辩护的人逗乐了,他们坚持说,你对SQL的任何问题都必须是你自己使用它的无能,而不是SQL的任何错误,你不能只是没有达到理解它的完美所必需的更高层次的思考,等等。冷静下来,深呼吸。我们在侮辱计算机语言,而不是你妈妈。

现在的总体趋势是NoSQL;一般来说,这些技术是:

• 将数据存储为键/值对的分布式“哈希表”
• Document-oriented databases

我个人认为只要SQL符合您的需要,它就没有什么问题。SQL具有表达能力,非常适合处理结构化数据。

回到20世纪80年代, ObjectStore 提供了透明的对象访问。它有点像RDBMS加上ORM,除了没有那些额外的泄漏抽象层:它直接将对象存储在数据库中。

所以这个选择实际上是“完全没有语言”,或者“你已经使用的语言”。您将编写C++代码,并创建或遍历对象,就好像它们是本地对象一样,数据库根据需要处理一切。有点像ActiveRecord,但实际上它和ActiveRecord的营销闪电一样有效。-)

(当然,它没有甲骨文的营销力量,也没有MySQL的零成本,所以大家都忽略了它。现在,我们尝试用RDBMS和ORM复制它,一些人试图争辩说,表实际上对存储对象是有意义的,编写大型XML文件告诉计算机如何将对象映射到表是一个合理的解决方案。)

我想你可能有兴趣看看 Dataphor 它是一个开放源码的关系开发环境,有自己的数据库服务器(说D),并且能够从其查询语言派生用户界面。

而且,它似乎 Ingres 仍然支持Quel,它是开源的。

有许多SQL实现(SQL Server、MySQL、Oracle等),但没有其他实现 语言 服务于 同一目的 作为一个 通用语言 设计用于 关系数据存储和检索 .

有 object databases 例如 db4o 还有类似的所谓 noSQL 仅引用任何数据存储机制的数据库 不 依赖于SQL,但最常见的开源产品是 Cassandra 基于谷歌的 Bigtable 概念。

还有一些特殊用途的数据库产品,比如CDF,但您可能不需要担心这些——如果您需要,您会知道。

这些都不等同于SQL。

这并不意味着它们“更好”或“更差”——它们只是不一样。丹尼斯福布斯写了一篇 great post 最近打破了一些针对SQL的奇怪声明。他坚持认为(我也同意)这些抱怨主要来自于那些从一开始就为工作选择了错误的工具,或者没有正确使用他们的SQL DBMS的人和商店(当我看到另一个SQL数据库,其中的每一列都是 varchar(50) 而且在任何地方都没有一个索引或键)。

如果你正在实施另一个社交网站,并且不太关心 ACID 原则,无论如何,开始研究像db4o这样的产品。 高度地 建议你在加入“SQL糟糕”合唱团之前三思而后行。首先进行研究,找出各种产品可以支持和不能支持的功能。

编辑-我正忙于写我的答案,几分钟后没有得到问题更新。尽管如此,SQL本质上是与DBMS本身不可分割的。如果您运行一个SQL数据库产品,那么您可以使用SQL、句点来访问它。

也许您正在寻找语法上的抽象;Linq to SQL、Entity Framework、Hibernate/NHibernate、SubSonic和许多其他ORM工具都提供了自己的类SQL的语法,而这些语法并不完全是SQL。所有这些“编译”到SQL。如果您运行SQL Server,那么您还可以编写clr函数/过程/触发器,这样您就可以用任何.NET语言编写将在数据库中运行的代码;但是,这并不能真正代替SQL,而更多的是它的扩展。

我不知道可以在SQL数据库之上分层的任何完整“语言”;除了切换到其他数据库产品之外,您最终将看到管道上的SQL。

对于设计它的相关数据表的域,SQL工作正常。这通常在传统的业务数据处理中发现。当试图持久化一个复杂的对象网络时,SQL不能很好地工作。

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

根据您的编辑:

如果您正在寻找从关系数据存储中检索数据的SQL DML的替代方案,我从来没有听说过SQL的任何重要替代方案。

我认为,与语言所基于的底层数据存储原则相比,SQL得到的敲打并不那么违背语言。人们常常将SQL语言与构建RDBMSE所基于的关系数据模型混淆。

实际上是SQL。

试图屏蔽开发人员的框架最终创建了自己的特定语言(HibernateHQL浮现在脑海中)。

SQL很好地解决了一个问题。学习高级编程语言并不比学习高级编程语言更困难。如果您已经了解了一种函数式语言,那么很容易掌握SQL。

考虑到提供最先进数据库(Oracle和SQL Server)的领先数据库供应商支持SQL,并已投入数年的时间在优化引擎等方面,以及所有领先的数据建模软件和变更管理软件都使用SQL,我认为这是最安全的赌注。

此外,对数据库来说,不仅仅是查询。有可扩展性、备份和恢复、数据挖掘。大厂商支持很多甚至新的“缓存”引擎都不考虑的事情。

关系数据库并不是周围唯一的一种数据库。我应该说一句 Object-Databases 因为我没有从别人的反应中看到。我对使用 ZODB 对于对象持久性而不是RDBMS(理论上可以用zope中的另一个数据库替换zodb,但是上次我检查时没有成功让它工作,所以不能肯定这一点)。

zodb的思维方式确实不同,更像是持久的对象编程。

ORM 可以看作是一种语言

在某种程度上,我相信对象数据库模型就是ORM的目的:通过通常的对象模型访问持久数据。它是一种语言,正在获得一些市场份额,但目前我们并不把它看作一种语言,而是一个抽象层。不过,我认为在对象数据库上使用ORM比在SQL上使用ORM效率高得多(换句话说,我碰巧使用了一些SQL数据库作为基础层)。

SQL的问题促使我编写了一个名为 SMEQL 在过去 Portland Pattern Repository wiki . 欢迎评论。它借鉴了功能编程和IBM的实验性业务系统12语言的思想。(我最初叫它TQL,但后来发现这个名字被取了。)

在.NET世界中,虽然它仍然具有SQL风格,但Linq to SQL将允许您将SQL和内存.NET处理数据进行良好的混合。它还简化了很多没有人真正想做的底层数据管道。

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

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

Michael Stonebraker在 The "NoSQL" Discussion has Nothing to Do With SQL .