为什么要使用 SQL 数据库？

Why use SQL database?

提问by martinthenext

I'm not quite sure stackoverflow is a place for such a general question, but let's give it a try.

我不太确定 stackoverflow 是解决此类一般问题的地方，但让我们尝试一下。

Being exposed to the need of storing application data somewhere, I've always used MySQL or sqlite, just because it's always done like that. As it seems like the whole world is using these databases (most of all software products, frameworks, etc), it is rather hard for a beginning developer like me to start thinking about whether this is a good solution or not.

由于需要在某处存储应用程序数据，我一直使用 MySQL 或 sqlite，只是因为它们总是那样做。看起来全世界都在使用这些数据库（大多数软件产品、框架等），对于像我这样的初学者来说，很难开始考虑这是否是一个好的解决方案。

Ok, say we have some object-oriented logic in our application, and objects are related to each other somehow. We need to map this logic to the storage logic, so relations between database objects are required too. This leads us to using relational database, and I'm ok with that - to put it simple, our database table rows sometimes will need to have references to other tables' rows. But why use SQL language for interaction with such a database?

好的，假设我们的应用程序中有一些面向对象的逻辑，并且对象以某种方式相互关联。我们需要将此逻辑映射到存储逻辑，因此也需要数据库对象之间的关系。这导致我们使用关系数据库，我可以接受 - 简单地说，我们的数据库表行有时需要引用其他表的行。但是为什么要使用 SQL 语言来与这样的数据库进行交互呢？

SQL query is a text message. I can understand this is cool for actually understanding what it does, but isn't it silly to use text table and column names for a part of application that no one ever seen after deploynment? If you had to write a data storage from scratch, you would have never used this kind of solution. Personally, I would have used some 'compiled db query' bytecode, that would be assembled once inside a client application and passed to the database. And it surely would name tables and colons by id numbers, not ascii-strings. In the case of changes in table structure those byte queries could be recompiled according to new db schema, stored in XML or something like that.

SQL 查询是一条文本消息。我可以理解这对于实际理解它的作用很酷，但是将文本表和列名称用于部署后没人见过的应用程序部分是否很愚蠢？如果您必须从头开始编写数据存储，您将永远不会使用这种解决方案。就个人而言，我会使用一些“已编译的数据库查询”字节码，这些字节码会在客户端应用程序中组装一次并传递给数据库。它肯定会通过 id 号而不是 ascii 字符串来命名表和冒号。在表结构发生变化的情况下，这些字节查询可以根据新的数据库模式重新编译，存储在 XML 或类似的东西中。

What are the problems of my idea? Is there any reason for me not to write it myself and to use SQL database instead?

我的想法有什么问题？有什么理由让我不自己编写而是使用 SQL 数据库？

EDITTo make my question more clear. Most of answers claim that SQL, being a text query, helps developers better understand the query itself and debug it more easily. Personally, I haven't seen people writing SQL queries by hand for a while. Everyone I know, including me, is using ORM. This situation, in which we build up a new level of abstraction to hide SQL, leads to thinking if we need SQL or not. I would be very grateful if you could give some examples in which SQL is used without ORM purposely, and why.

编辑为了让我的问题更清楚。大多数答案声称 SQL 作为文本查询，可以帮助开发人员更好地理解查询本身并更轻松地调试它。就我个人而言，我已经有一段时间没有看到人们手工编写 SQL 查询了。我认识的每个人，包括我，都在使用 ORM。在这种情况下，我们建立了一个新的抽象级别来隐藏 SQL，导致我们思考是否需要 SQL。如果您能举出一些故意在没有 ORM 的情况下使用 SQL 的示例，以及原因，我将不胜感激。

EDIT2SQL is an interface between a human and a database. The question is why do we have to use it for application/database interaction?I still ask for examples of human beings writing/debugging SQL.

EDIT2SQL 是人和数据库之间的接口。问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求提供人类编写/调试 SQL 的示例。

采纳答案by Jay

If all you need to do is store some application data somewhere, then a general purpose RDBMS or even SQLite might be overkill. Serializing your objects and writing them to a file might be simpler in some cases. An advantage to SQLite is that if you have a lot of this kind of information, it is all contained in one file. A disadvantage is that it is more difficult to read it. For example, if you serialize you data to YAML, you can read the file with any text editor or shell.

如果您需要做的只是在某处存储一些应用程序数据，那么通用的 RDBMS 甚至 SQLite 可能都有些过头了。在某些情况下，序列化对象并将它们写入文件可能更简单。SQLite 的一个优点是，如果您有大量此类信息，则它们都包含在一个文件中。缺点是阅读起来比较困难。例如，如果您将数据序列化为 YAML，则可以使用任何文本编辑器或 shell 读取该文件。

Personally, I would have used some 'compiled db query' bytecode, that would be assembled once inside a client application and passed to the database.

就个人而言，我会使用一些“已编译的数据库查询”字节码，这些字节码会在客户端应用程序中组装一次并传递给数据库。

This is how some database APIs work. Check out static SQL and prepared statements.

这就是一些数据库 API 的工作方式。查看静态 SQL 和准备好的语句。

Is there any reason for me not to write it myself and to use SQL database instead?

有什么理由让我不自己编写而是使用 SQL 数据库？

If you need a lot of features, at some point it will be easier to use an existing RDMBS then to write your own database from scratch. If you don't need many features, a simpler solution may be wiser.

如果您需要很多功能，在某些时候使用现有的 RDMBS 会更容易，然后从头开始编写您自己的数据库。如果您不需要很多功能，更简单的解决方案可能更明智。

The whole point of database products is to avoid writing the database layer for every new program. Yes, a modern RDMBS might not always be a perfect fit for every project. This is because they were designed to be very general, so in practice, you will always get additional features you don't need. That doesn't mean it is better to have a custom solution. The glove doesn't always need to be a perfect fit.

数据库产品的重点是避免为每个新程序编写数据库层。是的，现代 RDMBS 可能并不总是适合每个项目。这是因为它们的设计非常通用，因此在实践中，您将始终获得不需要的附加功能。这并不意味着拥有自定义解决方案更好。手套并不总是需要完美贴合。

UPDATE:

更新：

But why use SQL language for interaction with such a database?

但是为什么要使用 SQL 语言来与这样的数据库进行交互呢？

Good question.

好问题。

The answer to that may be found in the original paper describing the relational model A Relational Model of Data for Large Shared Data Banks, by E. F. Codd, published by IBM in 1970. This paper describes the problems with the existing database technologies of the time, and explains why the relational model is superior.

答案可以在描述关系模型A Relational Model of Data for Large Shared Data Banks的原始论文中找到，该论文由 EF Codd 撰写，IBM 于 1970 年出版。这篇论文描述了当时现有数据库技术的问题，并解释了为什么关系模型是优越的。

The reason for using the relational model, and thus a logical query language like SQL, is data independence.

使用关系模型以及 SQL 等逻辑查询语言的原因是数据独立性。

Data independence is defined in the paper as:

论文中将数据独立性定义为：

"... the independence of application programs and terminal activities from the growth in data types and changes in data representations."

“......应用程序和终端活动独立于数据类型的增长和数据表示的变化。”

Before the relational model, the dominate technology for databases was referred to as the network model. In this model, the programmer had to know the on-disk structure of the data and traverse the tree or graph manually. The relational model allows one to write a query against the conceptual or logical scheme that is independent of the physical representation of the data on disk. This separation of logical scheme from the physical schema is why we use the relational model. For a more on this issue, hereare some slides from a database class. In the relational model, we use logic based query languages like SQL to retrieve data. Codd's papergoes into more detail about the benefits of the relational model. Give it a read.

在关系模型出现之前，数据库的主导技术被称为网络模型。在这个模型中，程序员必须知道数据的磁盘结构并手动遍历树或图形。关系模型允许针对独立于磁盘上数据的物理表示的概念或逻辑方案编写查询。这种逻辑方案与物理方案的分离是我们使用关系模型的原因。关于这个问题的更多信息，这里有一些来自数据库类的幻灯片。在关系模型中，我们使用基于逻辑的查询语言（如 SQL）来检索数据。 Codd 的论文更详细地介绍了关系模型的好处。给它读一读。

SQL is a query language that is easy to type into a computer in contrast with the query languages typically used in a research papers. Research papers generally use relation algebra or relational calculus to write queries.

与研究论文中通常使用的查询语言相比，SQL 是一种易于在计算机中输入的查询语言。研究论文通常使用关系代数或关系演算来编写查询。

In summary, we use SQL because we happen to use the relational model for our databases.

总之，我们使用 SQL 是因为我们碰巧为我们的数据库使用了关系模型。

If you understand the relational model, it is not hard to see why SQL is the way it is. So basically, you need to study the relation model and database internals more in-depth to really understand why we use SQL. It may be a bit of a mystery otherwise.

如果您了解关系模型，就不难理解为什么 SQL 是这样的。所以基本上，你需要更深入地研究关系模型和数据库内部结构，才能真正理解我们为什么使用 SQL。否则它可能有点神秘。

UPDATE 2:

更新 2：

SQL is an interface between a human and a database. The question is why do we have to use it for application/database interaction? I still ask for examples of human beings writing/debugging SQL.

SQL 是人与数据库之间的接口。问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求提供人类编写/调试 SQL 的示例。

Because the database is a relational database, it only understands relational query languages. Internally it uses a relational algebra like language for specifying queries which it then turns into a query plan. So, we write our query in a form we can understand (SQL), the DB takes our SQL query and turns it into its internal query language. Then it takes the query and tries to find a "query plan" for executing the query. Then it executes the query plan and returns the result.

因为数据库是关系型数据库，所以只懂关系查询语言。在内部，它使用类似关系代数的语言来指定查询，然后将其转换为查询计划。因此，我们以我们可以理解的形式（SQL）编写我们的查询，DB 将我们的 SQL 查询转换为它的内部查询语言。然后它接受查询并尝试找到执行查询的“查询计划”。然后它执行查询计划并返回结果。

At some point, we must encode our query in a format that the database understands. The database only knows how to convert SQL to its internal representation, that is why there is always SQL at some point in the chain. It cannot be avoided.

在某些时候，我们必须以数据库可以理解的格式对我们的查询进行编码。数据库只知道如何将 SQL 转换为其内部表示，这就是为什么在链中的某个点总是存在 SQL。这是无法避免的。

When you use ORM, your just adding a layer on top of the SQL. The SQL is still there, its just hidden. If you have a higher-level layer for translating your request into SQL, then you don't need to write SQL directly which is beneficial in some cases. Some times we do not have such a layer that is capable of doing the kinds of queries we need, so we must use SQL.

当您使用 ORM 时，您只需在 SQL 之上添加一个层。SQL 仍然存在，只是被隐藏了。如果您有一个更高级别的层来将您的请求转换为 SQL，那么您不需要直接编写 SQL，这在某些情况下是有益的。有时我们没有这样的层能够执行我们需要的查询类型，因此我们必须使用 SQL。

回答by Donnie

Everyone I know, including me, is using ORM

我认识的每个人，包括我，都在使用 ORM

Strange. Everyone I know, including me, still writes most of the SQL by hand. You typically end up with tighter, more high performance queries than you do with a generated solution. And, depending on your industry and application, this speed doesmatter. Sometimes a lot. yeah, I'll sometimes use LINQ for a quick-n-dirty where I don't really care what the resulting SQL looks like, but thus far nothing automated beats hand-tuned SQL for when performance against a large database in a high-load environment really matters.

奇怪的。我认识的每个人，包括我，仍然手工编写大部分 SQL。与生成的解决方案相比，您通常会得到更紧密、更高性能的查询。而且，根据您的行业和应用，这样的速度确实问题。有时很多。是的，我有时会使用 LINQ 进行快速处理，在这种情况下我并不真正关心生成的 SQL 是什么样子，但到目前为止，在针对大型数据库的性能较高的情况下，没有任何自动化可以胜过手动调整的 SQL。负载环境真的很重要。

回答by Milan Babu?kov

Given the fact that you used MySQL and SQLite, I understand your point of view completely. Most DBMS have features that would require some of the programming from your side, while you get it from database for free:

鉴于您使用过 MySQL 和 SQLite，我完全理解您的观点。大多数 DBMS 都具有需要您进行一些编程的功能，而您可以从数据库中免费获得：

• Indexes- you can store large amounts of data and still be able to filter and search very quickly because of indexes. Of course, you could implement you own indexing, but why reinvent the wheel

• data integrity- using database features like cascading foreign keys can ensure data integrity across the system. You only need to declare relationship between data, and system takes care of the rest. Of course, once more, you could implement constraints in code, but it's more work. Consider, for example, deletion, where you would have to write code in object's destructor to track all dependent objects and act accordingly

• ability to have multiple applicationswritten in different programming languages, working on different operating systems, some even distributed across the network - all using the same datastored in a common database

• dead easy implementation of observer patternvia triggers. There are many cases where only some data depends on some other data and it does not affect UI aspect of application. Ensuring consistency can be very tricky or require a lot of programming. Of course, you could implement trigger-like behavior with objects but it requires more programming than simple SQL definition

• 索引- 您可以存储大量数据，并且由于索引的存在仍然能够非常快速地进行过滤和搜索。当然，您可以实现自己的索引，但为什么要重新发明轮子

• 数据完整性- 使用级联外键等数据库功能可以确保整个系统的数据完整性。您只需要声明数据之间的关系，其余的由系统来处理。当然，再一次，您可以在代码中实现约束，但这需要更多的工作。例如，考虑删除，您必须在对象的析构函数中编写代码以跟踪所有依赖对象并采取相应措施

• 能够使用不同的编程语言编写多个应用程序，在不同的操作系统上运行，有些甚至分布在网络上——所有应用程序都使用存储在公共数据库中的相同数据

• 通过触发器轻松实现观察者模式。在很多情况下，只有一些数据依赖于其他一些数据，并且不会影响应用程序的 UI 方面。确保一致性可能非常棘手或需要大量编程。当然，您可以使用对象实现类似触发器的行为，但它需要比简单的 SQL 定义更多的编程

回答by MBCook

There are some good answers here. I'll attempt to add my two cents.

这里有一些很好的答案。我会尝试添加我的两分钱。

I like SQL, I can think in it pretty easily. The queries produced by layers on top of the DB (like ORM frameworks) are usually hideous. They'll select tons of extra stuff, join in things you don't need, etc.; all because they don't know that you only want a small part of the object in this code. When you need high performance, you'll often end up going in and using at least some custom SQL queries in an ORM system just to speed up a few bottlenecks.

我喜欢 SQL，我可以很容易地思考它。由数据库顶部的层（如 ORM 框架）生成的查询通常是可怕的。他们会选择大量额外的东西，加入你不需要的东西，等等；都是因为他们不知道您只需要此代码中对象的一小部分。当您需要高性能时，您通常最终会在 ORM 系统中至少使用一些自定义 SQL 查询来加速一些瓶颈。

Why SQL? As others have said, it's easy for humans. It makes a good lowest common denominator. Any language can make SQL and call command line clients if necessary, and they is pretty much always a good library.

为什么是 SQL？正如其他人所说，这对人类来说很容易。它是一个很好的最小公分母。如有必要，任何语言都可以生成 SQL 和调用命令行客户端，而且它们几乎总是一个很好的库。

Is parsing out the SQL inefficient? Somewhat. The grammar is pretty structured, so there aren't tons of ambiguities that would make the parser's job really hard. The real thing is that the overhead of parsing out SQL is basically nothing.

解析 SQL 效率低下吗？有些。语法非常结构化，所以没有大量的歧义会使解析器的工作变得非常困难。真正的事情是解析出 SQL 的开销基本上没有。

Let's say you run a query like "SELECT x FROM table WHERE id = 3", and then do it again with 4, then 5, over and over. In that case, the parsing overhead may exist. That's why you have prepared statements (as others have mentioned). The server parses the query once, and can swap in the 3 and 4 and 5 without having to reparse everything.

假设您运行“SELECT x FROM table WHERE id = 3”之类的查询，然后使用 4 和 5 一遍又一遍地重复执行。在这种情况下，可能存在解析开销。这就是为什么你准备了陈述（正如其他人提到的）。服务器解析查询一次，并且可以交换 3、4 和 5，而无需重新解析所有内容。

But that's the trivial case. In real life, your system may join 6 tables and have to pull hundreds of thousands of records (if not more). It may be a query that you let run on a database cluster for hours, because that's the best way to do things in your case. Even with a query that takes only a minute or two to execute, the time to parse the query is essentially free compared to pulling records off disk and doing sorting/aggregation/etc. The overhead of sending the ext "LEFT OUTER JOIN ON" is only a few bytes compared to sending special encoded byte 0x3F. But when your result set is 30 MB (let alone gigs+), those few extra bytes are worthless compared to not having to mess with some special query compiler object.

但那是微不足道的情况。在现实生活中，您的系统可能会加入 6 个表，并且必须提取数十万条记录（如果不是更多的话）。它可能是您在数据库集群上运行数小时的查询，因为在您的情况下这是最好的处理方式。即使执行只需要一两分钟的查询，与从磁盘中提取记录并进行排序/聚合等相比，解析查询的时间基本上是免费的。与发送特殊编码字节 0x3F 相比，发送 ext "LEFT OUTER JOIN ON" 的开销只有几个字节。但是当您的结果集是 30 MB（更不用说 gigs+）时，与不必弄乱某些特殊查询编译器对象相比，那些额外的字节毫无价值。

Many people use SQL on small databases. The biggest one I interact with is only a few dozen gigs. SQL is used on everything from tiny files (like little SQLite DBs may be) up to terabyte size Oracle clusters. Considering it's power, it's actually a surprisingly simple and small command set.

许多人在小型数据库上使用 SQL。我与之互动的最大一场演出只有几十场演出。SQL 用于从微小文件（如小型 SQLite DB）到 TB 级大小的 Oracle 集群的所有内容。考虑到它的强大，它实际上是一个非常简单和小巧的命令集。

回答by ChrisW

But why use SQL language for interaction with such a database?

但是为什么要使用 SQL 语言来与这样的数据库进行交互呢？

I think it's for the same reason that you use a human-readable (source code) language for interaction with the compiler.

我认为这与您使用人类可读（源代码）语言与编译器交互的原因相同。

Personally, I would have used some 'compiled db query' bytecode, that would be assembled once inside a client application and passed to the database.

就个人而言，我会使用一些“已编译的数据库查询”字节码，这些字节码会在客户端应用程序中组装一次并传递给数据库。

This is an existing (optional) feature of databases, called "stored procedures".

这是数据库的现有（可选）功能，称为“存储过程”。

---

---

Edit:

编辑：

I would be very grateful if you could give some examples in which SQL is used without ORM purposely, and why

如果您能举出一些故意在没有 ORM 的情况下使用 SQL 的示例，以及为什么

When I implemented my own ORM, I implemented the ORM framework using ADO.NET: and using ADO.NET includes using SQL statements in its implementation.

当我实现自己的 ORM 时，我使用 ADO.NET 实现了 ORM 框架：并且使用 ADO.NET 包括在其实现中使用 SQL 语句。

回答by Michael Borgwardt

• It's an ubiquitous standard. Pretty much every programming language out there has a way to access SQL databases. Try that with a proprietary binary protocol.
• Everyone knows it. You can find experts easily, new developers will usually understand it to some degree without requiring training
• SQL is very closely tied to the relational model, which has been thoroughly explored in regard to optimization and scalability. But it still frequently requires manual tweaking (index creation, query structure, etc.), which is relatively easy due to the textual interface.

• 这是一个无处不在的标准。几乎每种编程语言都有访问 SQL 数据库的方法。尝试使用专有的二进制协议。
• 每个人都知道。您可以轻松找到专家，新开发人员通常会在一定程度上了解它，而无需培训
• SQL 与关系模型密切相关，关系模型已经在优化和可伸缩性方面进行了彻底的探索。但它仍然经常需要手动调整（索引创建、查询结构等），由于文本界面，这相对容易。

回答by Erwin Smout

After all the edits and comments, the main point of your question appears to be : why is the nature of SQL closer to being a human/database interface than to being an application/database interface ?

在进行了所有编辑和评论之后，您的问题的要点似乎是：为什么 SQL 的性质更接近于人/数据库界面而不是应用程序/数据库界面？

And the very simple answer to thatquestion is : because that is exactly what it was originally intended to be.

这个问题的非常简单的答案是：因为这正是它最初的意图。

The predecessors of SQL (QUEL being presumably the most important one) were intended to be exactly that : a QUERY language, i.e. one that didn't have any of INSERT, UPDATE, DELETE.

SQL 的前身（QUEL 可能是最重要的一个）就是这样一种语言：一种查询语言，即没有任何插入、更新、删除的语言。

Moreover, it was intended to be a query language that could be used by any user, provided that user was aware of the logical structure of the database, and obviously knew how to express that logical structure in the query language he was using.

此外，它旨在成为任何用户都可以使用的查询语言，前提是用户知道数据库的逻辑结构，并且显然知道如何用他正在使用的查询语言表达该逻辑结构。

The original ideas behind QUEL/SQL were that a database was built using "just any mechanism conceivable", that the "real" database could be really just anything (e.g. one single gigantic XML file - allthough 'XML' was not considered a valid option at the time), and that there would be "some kind of machinery" that understood how to transform the actual structure of that 'just anything' into the logical relational structure as it was perceived by the SQL user.

QUEL/SQL 背后的最初想法是使用“任何可以想象的机制”构建数据库，“真正的”数据库实际上可以是任何东西（例如一个巨大的 XML 文件 - 尽管“XML”不被认为是有效的选择当时），并且会有“某种机器”了解如何将“任何东西”的实际结构转换为 SQL 用户所感知的逻辑关系结构。

The fact that in order to actually achieve that, the underlying structures are required to lend themselves to "viewing them relationally", was not understood as well in those days as it is now.

为了真正实现这一目标，需要底层结构让自己“以关系方式查看它们”这一事实，在那些日子里并没有像现在这样被理解。

回答by Mark Byers

Yes, it is annoying to have to write SQL statements to store and retrieve objects.

是的，必须编写 SQL 语句来存储和检索对象很烦人。

That's why Microsoft have added things like LINQ (language integrated query) into C# and VB.NET to make it possible to query databases using objects and methods instead of strings.

这就是为什么微软在 C# 和 VB.NET 中添加了诸如 LINQ（语言集成查询）之类的东西，以便可以使用对象和方法而不是字符串来查询数据库。

Most other languages have something similar with varying levels of success depending on the abilities of that language.

大多数其他语言都有类似的东西，根据该语言的能力不同，成功程度也不同。

On the other hand, it is useful to know how SQL works and I think it is a mistake to shield yourself entirely from it. If you use the database without thinking you can write extremely inefficient queries and index the database incorrectly. But once you understand how to use SQL correctly and have tuned your database, you have a very powerful tried-and-tested tool available for finding exactly the data you need extremely quickly.

另一方面，了解 SQL 的工作原理很有用，我认为完全屏蔽它是错误的。如果您不加考虑地使用数据库，您可能会编写极其低效的查询并错误地索引数据库。但是，一旦您了解了如何正确使用 SQL 并调整了数据库，您就拥有了一个非常强大的、久经考验的工具，可用于极其快速地准确查找所需的数据。

回答by blissapp

My biggest reason for SQL is Ad-hoc reporting. That report your business users want but don't know that they need it yet.

我使用 SQL 的最大原因是临时报告。您的业​​务用户想要但不知道他们需要的报告。

回答by neoblitz

SQL is an interface between a human and a database. The question is why do we have to use it for application/database interaction? I still ask for examples of human beings writing/debugging SQL.

SQL 是人与数据库之间的接口。问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求提供人类编写/调试 SQL 的示例。

I use sqlite a lot right from the simplest of tasks (like logging my firewall logs directly to a sqlite database) to more complex analytic and debugging tasks in my day-to-day research. Laying out my data in tables and writing SQL queries to munge them in interesting ways seems to be the most natural thing to me in these situations.

我经常使用 sqlite，从最简单的任务（比如将我的防火墙日志直接记录到 sqlite 数据库）到我日常研究中更复杂的分析和调试任务。在这些情况下，将我的数据放在表中并编写 SQL 查询以有趣的方式处理它们对我来说似乎是最自然的事情。

On your point about why it is still used as an interface between application/database, this is my simple reasoning:

关于为什么它仍然用作应用程序/数据库之间的接口，这是我的简单推理：

1. There is about 3-4 decades of serious research in that area starting in 1970 with Codd's seminal paper on Relational Algebra. Relational Algebra forms the mathematical basis to SQL (and other QLs), although SQL does not completely follow the relational model.

2. The "text" form of the language (aside from being easily understandable to humans) is also easily parsable by machines (say using a grammar parser like like lex) and is easily convertable to whatever "bytecode" using any number of optimizations.

3. I am not sure if doing this in any other way would have yielded compellingbenefits in the generic cases. Otherwise it would have been probably discovered and adopted in the 3 decades of research. SQL probably provides the best tradeoffs when bridging the divide between humans/databases and applications/databases.

1. 从 1970 年 Codd 关于关系代数的开创性论文开始，在该领域进行了大约 3-4 年的认真研究。关系代数构成了 SQL（和其他 QL）的数学基础，尽管 SQL 并不完全遵循关系模型。

2. 该语言的“文本”形式（除了易于人类理解之外）也很容易被机器解析（比如使用像 lex 这样的语法解析器），并且可以使用任意数量的优化轻松转换为任何“字节码”。

3. 我不确定以任何其他方式这样做是否会在一般情况下产生 令人信服的好处。否则它很可能会在 3 年的研究中被发现和采用。在弥合人类/数据库和应用程序/数据库之间的鸿沟时，SQL 可能提供了最好的权衡。

The question that then becomes interesting to ask is, "What are the real benefits of doing SQL in any other "non-text" way?" Will google for this now:)

然后变得有趣的问题是，“以任何其他“非文本”方式执行 SQL 的真正好处是什么？现在会谷歌这个:)