SQL（语言）的好替代品是什么？

What are good alternatives to SQL (the language)?

提问by Brendan Long

I occasionally hear things about how SQL sucks and it's not a good language, but I never really hear much about alternatives to it. So, are other good languages that serve the same purpose (database access) and what makes them better than SQL? Are there any good databases that use this alternative language?

我偶尔会听到一些关于 SQL 很糟糕的事情，它不是一种好语言，但我从来没有真正听到过关于它的替代方案。那么，其他优秀的语言是否具有相同的目的（数据库访问），是什么让它们比 SQL 更好？有没有使用这种替代语言的好数据库？

EDIT: I'm familiar with SQL and use it all the time. I don't have a problem with it, I'm just interested in any alternatives that might exist, and why people like them better.

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

I'm also not looking for alternative kinds of databases (the NoSQL movement), just different ways of accessing databases.

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

采纳答案by Ken Bloom

I certainly agree that SQL's syntax is difficult to work with, both from the standpoint of automatically generating it, and from the standpoint of parsing it, and it's not the style of language we would write today if we were designing SQL for the demands we place on it today. I don't think we'd find so many varied keywords if we designed the language today, I suspect join syntax would be different, functions like GROUP_CONCATwould have more regular syntax rather than sticking more keywords in the middle of the parentheses to control its behavior... create your own laundry list of inconsistencies and redundancies in SQL that you'd like/expect to see smoothed out if we redesigned the language today.

我当然同意 SQL 的语法很难使用，无论是从自动生成它的角度还是从解析它的角度来看，如果我们为我们提出的需求设计 SQL，这不是我们今天编写的语言风格今天就在它上面。如果我们今天设计语言，我认为我们不会找到这么多不同的关键字，我怀疑 join 语法会有所不同，像GROUP_CONCAT这样的函数会有更规则的语法而不是在括号中间粘贴更多的关键字来控制其行为... 创建您自己的 SQL 不一致和冗余清单，如果我们今天重新设计语言，您希望/期望看到这些问题会得到解决。

There aren't any alternatives to SQL for speaking to relational databases (i.e. SQL as a protocol), but there are many alternatives to writing SQL in your applications. These alternatives have been implemented in the form of frontends for working with relational databases. Some examples of a frontend include:

对于与关系数据库对话的 SQL，没有任何替代方案（即 SQL 作为协议），但在应用程序中编写 SQL 有许多替代方案。这些替代方案已以前端的形式实现，用于处理关系数据库。前端的一些示例包括：

• SchemeQLand CLSQL, which are probably the most flexible, owing to their Lisp heritage, but they also look like a lot more like SQL than other frontends.
• LINQ (in .Net)
• ScalaQLand ScalaQuery(in Scala)
• SqlStatement, ActiveRecordand many others in Ruby,
• HaskellDB
• ...the list goes on for many other languages.

• SchemeQL和CLSQL，由于它们的 Lisp 传统，它们可能是最灵活的，但与其他前端相比，它们看起来也更像 SQL。
• LINQ（在 .Net 中）
• ScalaQL和ScalaQuery（在 Scala 中）
• SqlStatement、ActiveRecord和 Ruby 中的许多其他内容，
• 数据库
• ...这个列表还有许多其他语言。

I think that the underlying theme today is that rather than replace SQL with one new query language, we are instead creating language-specific frontends to hide the SQL in our regular every-day programming languages, and treating SQL as the protocolfor talking to relational databases.

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

回答by Mike Cialowicz

Take a look at this list.

看看这个列表。

Hibernate Query Languageis probably the most common. The advantage of Hibernate is that objects map very easily (nearly automatically) to the relational database, and the developer doesn't have to spend much time doing database design. Check out the Hibernate websitefor more info. I'm sure others will chime in with other interesting query languages...

Hibernate 查询语言可能是最常见的。Hibernate 的优点是对象非常容易（几乎自动）映射到关系数据库，开发人员不必花太多时间进行数据库设计。查看Hibernate 网站了解更多信息。我相信其他人会加入其他有趣的查询语言......

Of course, there's plenty of NoSQL stuff out there, but you specifically mention that you're not interested in those.

当然，那里有很多 NoSQL 的东西，但你特别提到你对这些不感兴趣。

回答by reinierpost

Perhaps you're thinking of the criticism C. Date and his friends have uttered against existing relational databases and SQL; they say the systems and language aren't 100% relational, and should be. I don't really see any real problem here; as far as I can see you can have a 100% relational system, if you want, just by disciplining the way in which you use SQL.

也许您正在考虑 C.Date 和他的朋友们对现有关系数据库和 SQL 的批评；他们说系统和语言不是 100% 相关的，而且应该是。我在这里没有看到任何真正的问题；就我所见，如果您愿意，只要规范您使用 SQL 的方式，您就可以拥有 100% 的关系系统。

What I personally keep running into is the lack of expressive power SQL inherits from its theoretical basis, relational algebra. One issue is the lack of support for the use of domain ordering, which you run into when you work with data marked by dates, timestamps, etcetera. I once tried to do a reporting application entirely in plain SQL on a database full of timestamps and it just wasn't feasible. Another is the lack of support for path traversal: most of my data look like directed graphs that I need to traverse paths in, and SQL can't do it. (It lacks "transitive closure". SQL-1999 can do it with "recursive subqueries" but I haven't seen them in actual use yet. There are also various hacks to make SQL cope but they're ugly.) These problems are also discussed by some of Date's writings, by the way.

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

Recently I was pointed at .QLwhich appears to address the transitive closure issue nicely, but I don't know whether it can resolve the issue with ordered domains.

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

回答by Erwin Smout

"I occasionally hear things about how SQL sucks and it's not a good language"

“我偶尔会听说 SQL 很糟糕，而且它不是一门好语言”

SQL is over thirty years old. Insights about "which features make something a 'good' language and which ones make it a 'bad' one" have evolved more rapidly than SQL itself.

SQL 已经有三十多年的历史了。关于“哪些特性使某些东西成为'好'语言，哪些特性使它成为'坏'语言”的见解比 SQL 本身发展得更快。

Also, SQL is not a language that conforms to current standards of "what it takes to be relational", so, SQL just isn't a relational language to boot.

此外，SQL 不是一种符合当前“关系所需的条件”标准的语言，因此，SQL 并不是一种可启动的关系语言。

"but I never really hear much about alternatives to it."

“但我从来没有真正听说过它的替代品。”

I invite you to ponder the possibility that you are trying to hear only in the wrong places (that is, the commercial DBMS industry exclusively).

我邀请您思考您是否只尝试在错误的地方（即商业 DBMS 行业）进行聆听的可能性。

"So, are other good languages that serve the same purpose (database access) and what makes them better than SQL?"

“那么，其他优秀的语言是否具有相同的目的（数据库访问），是什么让它们比 SQL 更好？”

Date&Darwen describe the features that a modern data manipulation language must conform to in their "Third Manifesto", the most recent version of which is laid down in their book "Databases, Types & the Relational Model".

Date&Darwen 在他们的“第三宣言”中描述了现代数据操作语言必须符合的特性，其最新版本在他们的“数据库、类型和关系模型”一书中有所规定。

"Are there any good databases that use this alternative language?"

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

If by "good", you mean something like "industrial-strength", then no. The closest thing available would probably be Dataphor.

如果“好”是指“工业强度”之类的东西，那么不是。最接近的可能是 Dataphor。

The Rel project offers an implementation for the Tutorial D language defined in "Databases, Types & The Relational Model", but the current prime goal of Rel is to be educational in nature.

Rel 项目为“数据库、类型和关系模型”中定义的 Tutorial D 语言提供了一个实现，但 Rel 当前的主要目标是具有教育意义。

My SIRA_PRISE project offers an implementation for "truly relational" data management, but I hesitate to also label it "an implementation of a language".

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

And of course, you might also look into some non-relational stuff, as some have proposed, but I personally dismiss non-relational data management as multiple decades of technological regression. Not worth considering, that is.

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

Oh, and by the way, a software system that is used to manage databases is not "a database", but "a DataBase Management System", "DBMS" for short. Just like a photograph is not the same thing as a camera, and if you are discussing cameras, and you want to avoid confusion, then you should be using the proper word "cameras" instead of "photograph".

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

回答by thiag0

Take a look at LINQ to SQL...

看看 LINQ to SQL...

Tried it out a couple months ago and never looked back....

几个月前尝试过，再也没有回头......

回答by Jay

Direct answer: I don't think there's any serious contender out there. DBase and its imitators (Foxpro, Codebase etc) was a contender for a while, but I think they basically lost the database query language war. There have been many other database products that had their own query language, like Progress and Paradox and several others I've used whose names I don't remember and surely many more that I never heard of. But I don't think any other contender even came close to getting a non-trivial share of the market.

直接回答：我认为没有任何严重的竞争者。DBase 和它的模仿者（Foxpro、Codebase 等）曾经是一个竞争者，但我认为他们基本上输掉了数据库查询语言之战。有许多其他数据库产品拥有自己的查询语言，例如 Progress 和 Paradox 以及我使用过的其他几个我不记得名字的产品，当然还有更多我从未听说过的产品。但我不认为任何其他竞争者甚至接近获得不平凡的市场份额。

As simple proof that there is a difference between a database format and a query language, the last version of DBase I used -- many years ago now -- offerred both the "traditional" DBase query language and SQL, both of which could be used to access the same data.

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

Side ramble: I wouldn't say that SQL sucks, but it has many flaws. With the benefit of the years of experience and hindsight we now have, I'm sure one could design a better query language. But creating a better query language, and convincing people to use it, are two very different things. Would it be enough better to convince people that it was worth the trouble of learning. People have invested many years of their lives learning to use SQL effectively. Even if your new language is easier to use, there would surely be a learning curve. And how would you migrate your existing systems from SQL to the new language? Etc. It can be done, of course, just like C++, C#, and Java have largely overthrown COBOL and FORTRAN. But it takes a combination of technical superiority and good marketing to pull it off.

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

Still, I get a chuckle out of people who rush forward to defend SQL anytime someone criticizes it, who insist that any problem you have with SQL must be your own ineptitude in using it and not any fault of SQL, that you must just not have reached the higher plane of thingking necessary to comprehend its perfection, etc. Calm down, take a deep breath: We are insulting a computer language, not your mother.

尽管如此，我还是从那些在有人批评 SQL 时冲上去捍卫 SQL 的人发出了笑声，他们坚持认为 SQL 遇到的任何问题都必须是你自己使用它的无能，而不是 SQL 的任何错误，你一定不能有达到了理解其完美所必需的更高层次，等等。冷静下来，深呼吸：我们在侮辱一种计算机语言，而不是你的母亲。

回答by Ken

Back in the 1980's, ObjectStoreprovided transparent object access. It was kind of like an RDBMS plus an ORM, except without all those extra leaky abstraction layers: it stored objects directly in the database.

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

So this alternative was really "no language at all", or perhaps "the language you're already using". You'd write C++ code and create or traverse objects as if they were native objects, and the database took care of everything as needed. Kind of like ActiveRecord but it actually worked as well as the ActiveRecord marketing blitzes claim. :-)

所以这个替代方案实际上是“根本没有语言”，或者“你已经在使用的语言”。您将编写 C++ 代码并创建或遍历对象，就好像它们是本机对象一样，而数据库会根据需要处理所有事情。有点像 ActiveRecord，但它实际上和 ActiveRecord 营销闪电战声称的一样有效。:-)

(Of course, it didn't have Oracle's marketing muscle, and it didn't have MySQL's zero-cost, so everybody ignored it. And now we try to replicate that with RDBMSs and ORMs, and some people try to argue that tables actually make sense for storing objects, and that writing giant XML file to tell your computer how to map objects to tables is somehow a reasonable solution.)

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

回答by Justin Ethier

The general movement these days is NoSQL; generally these technologies are:

近来普遍的运动是 NoSQL；通常这些技术是：

• Distributed "hashtables" that store data as key/value pairs
• Document-oriented databases

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

Personally I think there is nothing wrong with SQL as long as it fits your needs. SQL is expressive and great for working with structured data.

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

回答by Ken Bloom

I think you might be interested in looking at Dataphor, which is an open-source relational development environment with its own database server (which speaks D), and the ability to derive user interfaces from its query language.

我认为您可能对Dataphor 感兴趣，它是一个开源关系开发环境，拥有自己的数据库服务器（使用 D 语言），并且能够从其查询语言中获取用户界面。

Also, it appears Ingresstill supports QUEL, and it's open source.

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

回答by kriss

Relational Databases are not the only kind of databases around. I should say a word about Object-Databasesas I havn't seen it in responses from others. I had some experience with the Zope python framework that use ZODBfor objects persistency instead of RDBMS (well, it's theoretically possible to replace ZODB by another database within zope but the last time I checked I didn't succeed to have it working, so can't be positive about that).

关系数据库并不是唯一的数据库类型。我应该说一下对象数据库，因为我还没有在其他人的回复中看到它。我对 Zope python 框架有一些经验，该框架使用ZODB而不是 RDBMS 来实现对象持久性（好吧，理论上可以用 zope 中的另一个数据库替换 ZODB，但上次我检查时没有成功让它工作，所以可以对此不要持肯定态度）。

The ZODB mindset is really different, more like object programming that would happen to be persistent.

ZODB 的思维方式确实不同，更像是碰巧是持久性的对象编程。

ORMcan be seen as a kind of language

ORM可以看作是一种语言

In a way I believe the Object-database model is what ORM are about : accessing persistent data through your usual object model. It's a kind of language and it's gaining some market share, but for now we don't see it as a language but as an abstraction layer. However I believe it would be much more efficient to use an ORM over an Object-database than over SQL (in other words performance of ORMs I happened to use using some SQL database as base layers sucked).

在某种程度上，我相信对象数据库模型就是 ORM 的意义所在：通过您常用的对象模型访问持久数据。它是一种语言并且正在获得一些市场份额，但现在我们不将其视为一种语言，而是将其视为一种抽象层。但是，我相信在对象数据库上使用 ORM 比在 SQL 上使用更有效（换句话说，我碰巧使用某些 SQL 数据库作为基础层使用的 ORM 的性能很差）。