为什么要使用 SQL 数据库？ [关闭]答案

【问题标题】：Why use SQL database? [closed]为什么要使用 SQL 数据库？ [关闭]
【发布时间】：2011-02-23 10:14:20
【问题描述】：

我不太确定 stackoverflow 是否适合提出此类一般性问题，但让我们试一试。

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

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

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

我的想法有什么问题？我有什么理由不自己写，改用 SQL 数据库吗？

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

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

【问题讨论】：

当我读到标题的时候，我以为这是一个愚蠢的问题……但它实际上是一个非常有趣的想法！
也许问题应该是，“为什么在数据库中使用 SQL 与编译查询”？
我通常手写 SQL（当然，我的查询不是很复杂）。
@martinthenext。回复：“我仍然要求提供人类编写/调试 SQL 的示例”。你是认真的吗？
NoSQL Google 组也适合这种查询。

标签： sql database database-design data-structures

【解决方案1】：

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

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

大多数其他语言都有类似的东西，但成功程度不同，具体取决于该语言的能力。

另一方面，了解 SQL 是如何工作的很有用，我认为完全保护自己不受它的影响是错误的。如果您不加思索地使用数据库，您可能会编写效率极低的查询并错误地索引数据库。但是，一旦您了解了如何正确使用 SQL 并调整了您的数据库，您就拥有了一个非常强大且久经考验的工具，可以非常快速地准确找到您需要的数据。

【讨论】：

在我看来，LINQ 语句被进一步转换为 SQL，并且与 db 的整个交互都像往常一样完成。这无疑是一个不使用蹩脚 SQL 的好方法，但它并不能消除我所写的数据库接口的整个问题。
@martinthenext：使用 LINQ to SQL，如果数据库发生更改（例如列名更改），您可以调整 DBML 文件。无需更改代码。

【解决方案2】：

有很多非关系数据库系统。这里仅仅是少数： Memcached Tokyo Cabinet

【讨论】：

但是我需要我的数据库是关系型的！我只是不想让它使用 SQL。
您当然可以使用非关系型数据库，但可以以您喜欢的任何方式构建数据。但它不会有任何自动完整性或级联更新/删除功能。

【解决方案3】：

创建 SQL 是为了提供一个接口来对关系数据库进行即席查询。

通常，大多数关系数据库都理解某种形式的 SQL。

存在面向对象的数据库，并且（可能）使用对象进行查询......但据我了解，OO 数据库有更多的耳闻，而关系数据库工作得很好。

关系数据库还允许您在“断开连接”状态下操作。获得所需信息后，您可以关闭数据库连接。使用 OO 数据库，您要么需要返回与当前对象相关的所有对象（以及它们相关的对象......以及......等等），要么重新打开连接以检索新对象访问。

除了 SQL，您还拥有将对象映射到 SQL 并返回的 ORM（对象关系映射）。其中有很多，包括 LINQ (.NET)、MS Entity Framework (.NET)、Hibernate (Java)、SQLAlchemy (Python)、ActiveRecord (Ruby)、Class::DBI (Perl) 等。 .

【讨论】：

【解决方案4】：

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

【讨论】：

1) 如果我说错了，我很抱歉，但为什么要使用 proprietary 这个词？例如，我正在考虑一些开源解决方案。 2) 3) 对开发人员来说，拥有文本查询似乎是件好事，因为它们很容易理解。但是那些花费大量时间在查询优化上的开发人员呢？这值得么？我不认为一个好的字节码查询应用程序接口，就像我所写的那样，会如此难以理解。我猜开发人员更喜欢速度而不是学习简单性。
@martinthenext - 问题在于互操作性。 SQL 是文本，可以轻松复制/粘贴、查看等。使用编译版本，您需要一个应用程序。您是否将一个集成到每个数据库中，创建一个适用于所有数据库的外部数据库？不同的操作系统，甚至数据库系统和每个版本之间的功能变化如何？ SQL 没有任何这些问题...直到您使用 SQL 构建器:)
...这可能是 XML 被如此广泛使用的原因。 XML 效率不高，但文本比某些二进制格式更容易处理。损坏的 XML 文件比二进制文件等更容易修复（至少由人修复）。
@martinthenext：听起来您认为查询优化是必要的，因为它是一种文本格式。没有什么比真相更遥远。查询（和数据库结构）优化涉及数据库和查询的语义结构和内容。如果没有其他工具，二进制格式只会使这种优化变得不可能。

【解决方案5】：

如果第一部分您似乎指的是通常所说的对象 - 关系映射阻抗。已经有很多框架可以缓解这个问题。也有权衡。有些事情会更容易，有些事情会变得更复杂，但在一般情况下，如果你能负担得起额外的层，它们会很好地工作。

在第二部分中，您似乎抱怨 SQL 是文本（它使用字符串而不是 id 等）... SQL 是一种查询语言。任何旨在由人类阅读或书写的语言（计算机或其他）都是面向文本的。程序集、C、PHP，应有尽有。为什么？因为，嗯……它确实有道理，不是吗？

如果您想要预编译查询，您已经有了存储过程。准备好的语句也会即时编译一次，IIRC。无论如何，大多数（如果不是全部）数据库驱动程序都使用二进制协议与数据库服务器通信。

【讨论】：

我在您的帖子上写了一个大评论，然后将其发布为编辑。我实际上并没有抱怨 SQL，我问的是为什么我们需要它 - 一种用于 HUMAN 和 DATABASE 之间接口的额外语言，因为在大多数情况下我们需要 APPLICATION/DATABASE 交互。
没有人参与就没有应用程序/数据库交互。还没有。

【解决方案6】：

是的，文本有点低效。但实际上获取数据的成本要高得多，因此基于文本的 sql 相当微不足道。

【讨论】：

【解决方案7】：

数据库语言很有用，因为它为您的数据提供了一个独立于任何使用它的应用程序的逻辑模型。然而，SQL 有很多缺点，尤其是它与其他语言的集成很差，类型支持比业界其他语言落后大约 30 年，而且它从来都不是真正的关系语言。

SQL 之所以能幸存下来，主要是因为数据库市场一直并且仍然由三大供应商主导，这些供应商在保护自己的投资方面拥有既得利益。这种情况正在发生变化，SQL 的时代可能已经屈指可数，但最终将取代它的模型可能还没有到来——尽管这些天有很多竞争者。

【讨论】：

哎哟。 “最终将取代它的模型”已经到来了。 1969/1970 年。它被称为数据的关系模型:-)

【解决方案8】：

至于找到一个不使用 SQL 作为其主要接口的关系数据库，我想你不会找到它。原因：SQL 是谈论关系的好方法。我不明白为什么这对您来说很重要：如果您不喜欢 SQL，请对其进行抽象（如 ORM），这样您就不必担心它了。让抽象担心它。它会把你带到同一个地方。

但是，您真正在这里提到的问题是对象-关系断开 - 问题在于关系本身。对象和关系元组并不总是让自己成为 1-1 关系，这就是开发人员对数据库感到沮丧的原因。解决方案是使用不同的数据库类型。

【讨论】：

我不同意你的第二句话。 SQL 是一种真正糟糕的“谈论关系”的方式！在很多方面，SQL 完全无法提供关系模型应该提供的功能。
@David - 有更好的建议吗？

【解决方案9】：

我认为大多数人都没有得到您的问题，尽管我认为这很清楚。不幸的是，我没有“正确”的答案。我猜这是几件事的结合：

设计时的半任意决定，例如易用性、不需要 SQL 编译器（或 IDE）、可移植性等。
碰巧流行起来（可能是由于类似的原因）
现在由于历史原因（兼容性、众所周知、经过验证等）仍在继续使用。
我认为大多数公司都不会为其他解决方案而烦恼，因为它运行良好，不是太大的瓶颈，它是一个标准，等等，等等..

【讨论】：

【解决方案10】：

虽然我明白你的意思，但 SQL 的查询语言有一席之地，尤其是在具有大量数据的大型应用程序中。并且要指出的是，如果没有这种语言，就不能称它为 SQL（结构化查询语言）。与您描述的方法相比，使用 SQL 的好处是 SQL 通常具有很高的可读性，尽管有些确实限制了他们的查询。

我完全同意 Mark Byers 的观点，你不应该让自己远离 SQL。任何开发人员都可以编写 SQL，但要真正让您的应用程序在 SQL 交互方面表现出色，了解该语言是必须的。

如果所有内容都如您所描述的那样使用字节码进行预编译，那么在原始开发人员离开后（或者甚至在 6 个月没有看到代码之后），我不希望成为必须调试应用程序的人。

【讨论】：

【解决方案11】：

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

索引 - 由于索引，您可以存储大量数据并且仍然能够非常快速地过滤和搜索。当然，您可以实现自己的索引，但为什么要重新发明轮子
数据完整性 - 使用级联外键等数据库功能可以确保整个系统的数据完整性。您只需要声明数据之间的关系，剩下的交给系统处理。当然，再一次，您可以在代码中实现约束，但这需要更多的工作。例如，考虑删除，您必须在对象的析构函数中编写代码来跟踪所有依赖对象并采取相应措施
能够使用不同的编程语言编写多个应用程序，在不同的操作系统上运行，有些甚至分布在网络上——所有应用程序都使用存储的相同的数据在一个通用数据库中
通过触发器轻松实现观察者模式。在很多情况下，只有一些数据依赖于其他一些数据，并且不会影响应用程序的 UI 方面。确保一致性可能非常棘手或需要大量编程。当然，您可以使用对象实现类似触发器的行为，但它需要比简单的 SQL 定义更多的编程

【讨论】：

多个应用程序的重大突破。许多开发人员习惯于 Web 应用程序或其他情况，您可以将应用程序直接一对一映射到数据库。在很多企业情况下，情况并非如此。您有一个数据库，其中可能有 2 个、3 个甚至十几个应用程序都在使用相同的数据。我见过的最常见的场景之一是两部分处理应用程序和报告应用程序。通常由不同的群体用不同的语言编写。尝试使用 ORM 进行这项工作非常困难。直接的 SQL 让它变得简单。
我同意为什么要重新发明轮子？这正是您在每次创建新应用程序时创建单独且唯一的数据库 - 应用程序交互时必须做的事情。

【解决方案12】：

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

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

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

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

编辑：

如果您能给出一些故意在没有 ORM 的情况下使用 SQL 的示例，我将非常感激，以及为什么

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

【讨论】：

【解决方案13】：

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

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

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

我有什么理由不自己编写并使用 SQL 代替数据库？

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

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

更新：

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

好问题。

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

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

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

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

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

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

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

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

更新 2：

SQL 是人与人之间的接口和一个数据库。问题是为什么我们必须使用它应用程序/数据库交互？一世还是求人的例子编写/调试 SQL。

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

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

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

【讨论】：

最终，他要问的是，如果 SQL 是为人类访问数据库而设计的，那么为什么计算机使用它而不是更好地为计算机设计的系统？
计算机对自己的数据还不感兴趣。

【解决方案14】：

Unix 设计原则之一可以这样说，“编写程序来处理文本流，因为这是一个通用接口。”。

我相信，这就是为什么我们通常使用 SQL 而不是一些只有编译接口的“字节 SQL”。即使我们确实有一个字节SQL，有人会写一个“文本SQL”，循环就会完成。

此外，MySQL 和 SQLite 的功能不如 MSSQL 和 Oracle SQL。所以你仍然处于 SQL 池的低端。

【讨论】：

【解决方案15】：

我认为问题的前提是不正确的。可以将 SQL 表示为文本是无关紧要的。大多数现代数据库只会编译一次查询并缓存它们，因此您已经拥有有效的“编译字节码”。尽管我不确定是否有人这样做，但没有理由不能在客户端方面发生这种情况。

你说 SQL 是一条短信，我认为他是一个信使，而且，正如我们所知，不要对信使开枪。真正的问题是关系并不是组织现实世界数据的一种足够好的方式。 SQL 只是猪的口红。

【讨论】：

【解决方案16】：

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

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

【讨论】：

+1 - 通过良好的架构设计，SQL 变得更易于使用。
@Fogle - 它专门针对他的两次编辑，询问人们仍在手写 SQL 而不是使用 ORM / 自动生成的查询的示例。
@RP - 我想我们实际上是在说同样的话。 ORM 会做很多基本的东西，而基本的东西就是大部分的东西。在我使用 Hibernate 期间，我不得不分离可能 1 或 2 个查询，事后看来，我应该完全放弃查询并使用内存中的优先队列管理那部分数据（时间敏感的东西）。跨度>
+1：虽然 ORM 让简单的查询变得更加容易，但它们似乎（至少对我而言）让困难的查询变得更加困难。
与手写查询相比，使用 ORM 也往往会产生大量查询。

【解决方案17】：

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

【讨论】：

【解决方案18】：

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

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

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

解析 SQL 效率低吗？有些。语法非常结构化，因此没有大量的歧义会使解析器的工作变得非常困难。实际是解析出SQL的开销基本没有。

假设您运行“SELECT x FROM table WHERE id = 3”之类的查询，然后用 4 再次执行此操作，然后是 5，一遍又一遍。在这种情况下，可能存在解析开销。这就是您准备声明的原因（正如其他人所提到的）。服务器解析一次查询，可以在3和4和5之间交换，而无需重新解析所有内容。

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

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

【讨论】：

【解决方案19】：

SQL 是人与人之间的接口和一个数据库。问题是为什么我们必须使用它应用程序/数据库交互？一世还是求人的例子编写/调试 SQL。

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

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

大约有 3-4 个十年该领域的认真研究从 1970 年 Codd 的开创性开始关于关系代数的论文。关系代数形成 SQL 的数学基础（和其他 QLs），虽然 SQL 没有完全遵循关系模型。
语言的“文本”形式（除了容易人类可以理解）也是很容易被机器解析（比如使用类似的语法解析器 lex) 并且可以使用任意数量的优化轻松转换为任何“字节码”。
我不确定是否在任何其他方式会产生在一般情况下引人注目的好处。否则它可能会被发现并在 3 年中采用研究。 SQL 可能提供桥接时的最佳权衡人类/数据库之间的划分和应用程序/数据库。

接下来要问的问题是，“以任何其他“非文本”方式执行 SQL 的真正好处是什么？”现在会谷歌这个:)

【讨论】：

【解决方案20】：

实际上有一些非SQL数据库（如Objectivity、Oracle Berkeley DB等）产品来了，但没有一个成功。将来如果有人找到 SQL 的直观替代方案，那将回答您的问题。

【讨论】：

虽然 SQL 是无可争议的数据库访问之王，但我认为没有任何方法可以说 Berkeley DB 的“它们都没有成功”。不，它不像典型的 SQL 数据库那样通用（它是一个键值存储），但它非常成功。多年来，它已在数千种应用中使用，并且仍然在很多地方大量使用。

【解决方案21】：

SQL 是 DBMS 平台使用的通用接口——接口的全部意义在于，所有数据库操作都可以在 SQL 中指定，而无需额外的 API 调用。这意味着系统的所有客户端（应用软件、报告和临时查询工具）都有一个通用接口。

其次，随着查询变得越来越复杂，SQL 变得越来越有用。尝试使用 LINQ 指定一个 12 路连接，其中包含三个基于存在谓词的条件和一个基于在子查询中计算的聚合的条件。这种事情在 SQL 中相当容易理解，但在 ORM 中不太可能。

在许多情况下，ORM 将完成您想要的 95% - 应用程序发出的大多数查询都是简单的 CRUD 操作，ORM 或其他通用数据库接口机制可以轻松处理。有些操作最好使用自定义 SQL 代码来完成。

但是，ORM 并不是数据库接口的全部和全部。 Fowler's Patterns of Enterprise Application Architecture 对其他类型的数据库访问策略有相当好的部分，并讨论了每种类型的优点。

通常有充分的理由不使用 ORM 作为主数据库接口层。一个好的例子是，像 ADO.Net 这样的平台数据库库通常做得足够好，并且可以很好地与环境的其余部分集成。您可能会发现使用其他界面的好处并没有真正超过集成带来的好处。

但是，您不能真正忽略 SQL 的最后一个原因是，如果您正在开发数据库应用程序，那么您最终将使用数据库。有很多很多关于商业应用程序代码错误的 WTF 故事都是由不正确理解数据库的人完成的。考虑不周的数据库代码可能会在很多方面造成麻烦，并且轻率地认为您不需要了解 DBMS 的工作原理是一种傲慢的行为，总有一天会咬您一口。更糟糕的是，它会来咬其他继承你代码的可怜的 schmoe。

【讨论】：

【解决方案22】：

因为通常情况下，您无法确定（引用您的话）“部署后从未见过”。知道有一个用于报告和数据集级别查询的简单界面是发展您的应用程序的好方法。
没错，在某些情况下还有其他可能有效的解决方案：XML、纯文本文件、OODB...
但是拥有一组通用接口（如 ODBC）对于数据的生命周期来说是一个巨大的优势。

【讨论】：

【解决方案23】：

在所有的编辑和 cmets 之后，您的问题的主要观点似乎是：为什么 SQL 的本质更接近于作为人/数据库接口而不是作为应用程序/数据库接口？

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

SQL 的前身（QUEL 可能是最重要的一种）旨在完全是这样：一种查询语言，即没有任何 INSERT、UPDATE、DELETE 的语言。

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

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

为了真正实现这一点，需要底层结构来“以相关方式查看它们”，这一事实在当时并没有像现在这样被理解。

【讨论】：

XML 当时不存在。
也不是 sql 是您可以执行的所有数据操作中最完整的语言吗？如果你没有这个 - 你如何构建应用程序（连接到数据库）？这些应用程序每次都必须使用新的个人语言。这就像每次开发一个新的应用程序时都开发一个新的 Java 语言（并且只包含该特定程序中需要的内容）。
@lealo 这个答案的重点是 SQL 之所以如此，是因为它的设计主要考虑了坐在控制台前直接向 DBMS 输入命令的用户.对于编写解决 DBMS 的程序的程序员来说，这不是最合适的接口类型，这一点相当明显。所以我们有一个相对奇怪的情况，即“低级、技术性”的编程语言要求助于“高级/最终用户级”的语言来完成他们的数据库数据操作。它可能会有所不同，但事实并非如此......
...正如您正确观察到的那样，这可能会导致“另一种”语言宿主：用于与 COBOL 集成的语言，使实际数据接口看起来像 COBOL，该语言意味着用于与 C 的集成，使实际的数据接口看起来像 C)ish 等等等等 (你似乎认为这必然并且根据定义是一件坏事，但我不同意 (这意味着我不太确定比你看起来的那样）。）
不，您不必“重新发明”算法，因为算法是根据数学定义的，无论实现它们的语言如何，数学都适用。所以没有“重新发明”，只是在某种程度上“重新实施”。不，这不一定是坏事。用于寻址内存的“算法”一直在重新实现。当我们发现“一个 Meg 终究不满足任何人”，当我们发现“16 Meg 终究不够”（大型机从 MVS 到 MVS/XA 的过渡）时，当我们发现毕竟 32 位是不够的，等等等等。

【解决方案24】：

我认为你可以使用 ORM

当且仅当您了解 sql 的基础知识。

否则结果不是最好的

【讨论】：

【解决方案25】：

我认为原因可能是 sql laungage 所连接的搜索/查找/抓取算法。请记住，sql 已经开发了 40 年 - 目标是性能明智和用户友好。

问问自己找到 2 个属性的最佳方法是什么。现在为什么要在每次开发应用程序时都想做一些包含该内容的事情时进行调查。假设开发应用程序的主要目标是开发您的应用程序。

一个应用程序与其他应用程序有相似之处，一个数据库与其他数据库有相似之处。所以应该有一个“最好的方式”在逻辑上进行交互。

同时问问自己如何开发一个更好的不使用 sql laungage 的仅限控制台的应用程序。如果你不能做到这一点，我认为你需要开发一种新的 GUI，它比控制台更容易使用 - 从中开发东西。这实际上是可能的。但是大多数应用程序的开发仍然基于控制台和打字。

那么当涉及到 laungage 时，我认为您无法制作比 sql 更简单的文本 laungage。请记住，任何事物的每个词都与它的含义密不可分——如果你删除了这个词的含义，这个词就无法使用——如果你删除了这个词，你就无法传达它的含义。你没有什么可以形容它的（也许你甚至无法想到它，因为它不会与你之前想到的任何其他东西联系起来......）。

所以基本上最好的数据库操作算法被分配给单词 - 如果你删除这些单词，你将不得不为这些操作分配其他东西 - 那会是什么？

【讨论】：