不带SQL的RDBMS[关闭]

Question

原关闭原因未解决

存在没有SQL的RDBMS吗。我不是在谈论NoSQL和所有XML和Javascript对象类型的数据。

我的意思是像数据库一样，它不是通过SQL来指示的，而是通过一些API来指示的。根本不应该有SQL。

我的意思是，就像MS过去的ADO对象一样，这些对象有方法来完成SQL目前所做的所有事情。

我并不是在要求一个ORM框架。这些框架只是在内部生成和调用SQL代码。我不想那样。我想要直接与数据库对话的直接函数或方法调用。

我喜欢windows平台。我希望RDBMS支持的语言是PHP和Python；也许还有C#。

我想要管理的数据是日常SQL-RDBMS处理的所有数据。

是的，我希望DBMS管理实体关系。但我不希望SQL出现在画面中。

我不是在为任何人做项目。避免从一个层次/语言跳到另一个层次/语言只是口味或偏好的问题。

我试着在谷歌上搜索，但它只会导致我不喜欢的非关系型数据库。

Answer 1

您是否在询问关系数据库管理系统（“关系”形容词是最重要的一个）？它们中的大多数（以及几乎所有）或多或少都是基于SQL的（但你可能会发现一些学术软件不是这样的；一个没有名字的“马”（Rel）。还可以阅读有关对象数据库的更多信息

如果关系方面对您很重要，为什么不使用SQL呢？这是一个众所周知的事实标准（是的，我们知道SQL有局限性，并不完全是关系型的）。还可以阅读有关数据日志的内容。

也许您需要一些键值存储。然后你可以考虑GDBM（参见这里的文档），或者ReDIS，京都内阁等等。注意，REDIS可以从C#使用（我没有检查其他的），而REDIS可以从PHP使用。

也许你想要一个库，而不是一个服务器DBMS；如果SQL是可接受的，请查看sqlite（您将只使用一个API，但该API有时需要一些SQL请求）。sqlite可以从C#中使用，sqlite可以从PHP中使用。

你有没有研究过MongoDB（注意JSON和JavaScript不一样）？

^{我们无法猜测您正在开发的应用程序和您想要管理的数据！}

如果您对SQL过敏，不想使用极少数学术竞争对手（如Rel），并且仍然需要关系数据库系统，那么您必须自己设计和构建它。这可能需要十几年的时间，并且可能会让你获得博士学位（如果你成功并发表学术论文的话）。最大的问题是构建高效、可扩展且具有ACID特性的东西。你需要学习很多东西（注意，RDBMS是一个很大的软件：PostGreSQL 9.5大约有790KLOC的源代码，用sloccount来衡量；MySQL 5.7是2180KLOC，包括TestSuite）

顺便说一句，一些编程语言（例如opa）声称同时处理浏览器客户端、服务器端和数据库方面的问题。也许你可以试一下？

Answer 2

我没有答案，但也许我可以澄清这个问题。很多人在谈论SQL，好像它是一种查询数据库本身的语言。然而，SQL被转换成关系代数的形式，然后在数据库结构上产生进程。关系代数（至少在理论上）是查询关系对象结构的基本层次。我也希望看到一个完全没有SQL的关系数据库。SQL是由键盘而不是代码编写的。编写像关系代数那样处理事情的通用SQL编写器是非常困难的。关系代数是正交的，可以在不影响结果（仅性能）的情况下重新排列。对于像SQL这样的语言来说，在不同的时间、出于不同的原因在整个代码库中添加where子句是非常困难的，但是对于像关系代数这样的正交操作来说，这是微不足道的。

事实上，据我所知。关系数据库将SQL转换为某种形式的关系代数，以便对其进行性能优化。为什么不跳过中间人，在客户端创建关系代数并将其直接发送到数据库？

我绝对明白有些人只是在解释风景，我不想反对我们所处的位置。

我相信对于postgres这样的数据库，有几种语言可供选择，但它们非常不标准，不幸的是，使用它们是有风险的，因为它们通常没有得到很好的维护，而且它们也不为人所知，因此将开发人员添加到您的组织中是一个挑战。

希望有一天有人会开发一个易于部署的数据库，使用与关系代数更密切相关的东西。

下面是一个可以安装在postgres上的更接近关系代数的语言示例。http://www.andl.org/

这个项目（至少是网页）实际上是最近更新的07/2020

Answer 3

我认为这是一个完全合理的问题。为什么必须使用SQL来查询数据库，而不是一些低级API？我认为有几个原因——不完全是答案：

>

SQL试图为任何数据库实现提供标准接口。

使用准备好的语句可以降低解析SQL的成本。

另外，一些开发人员非常面向数据库和SQL，而另一些开发人员非常面向编程语言。尽管经常处于对立状态，但这些技能在许多方面是互补的。

“nosql”的出现使人们在尝试在实现端使用不同的数据布局的同时，重新尝试将SQL作为接口进行改进。许多“nosql”一代人正在发明自己的查询语言。还有像ApacheDrill这样的项目，它们试图通过一个通用API再次访问所有数据库。

但是为什么不提供一个低级接口来避免解析SQL的成本呢？一个答案是，数据库现在通过提供准备好的语句来降低成本。SQL被解析一次，之后你有一个或多或少代表低级API的参数化查询对象。

您可以通过使用库或手工编制的数据结构以及针对特定用例的手工编码查询来提高性能。例如，如果您只需要一个键/值存储，您可以使用哈希映射或REDIS或其他任何东西。

解析SQL是有危险的，比如SQL注入。通过创建以安全方式转换为SQL的API，可以避免这些问题。例如ORM或类似LINQ的东西。从理论上讲，它们可以分解为一个低级API，而不用一起创建SQL。这必须逐个数据库完成，正如您所注意到的，大多数数据库都专注于提供SQL接口，通常根本不公开低级API。在我看来，一个好的数据库库应该尝试提供一个API，使这在原则上成为可能（即，从SQL中抽象出来），然后它可以成为一个在给定语言中标准化的候选者。大多数都只是包装SQL，不要试图将其抽象得太远，因为这是一项艰巨的任务。

伯克利数据库书中“SQL有什么不好”一节中有一句关于SQL的话。如果你google一下，你可能也会点击这样的页面

这或多或少只是为问题辩护，而不是回答问题。最接近答案的可能是我上面说过的准备好的陈述。

为了优化查询计划，您可能最终需要特定于数据库（这可能就是为什么您首先希望使用较低级别的API？）。