单表关系数据库是否类似于简单的 NoSQL 数据库?

use*_*631 7 nosql rdbms sqlite

NoSQL 数据库吹捧的一个优势是缺乏模式。在单表关系型数​​据库的情况下,多表之间没有关系,可以很容易地向单表添加新列。看起来它和 NoSQL 数据库一样好,因为不需要设计模式。那么,单表关系数据库是否类似于简单的 NoSQL 数据库?

考虑到像 SQLite 这样的关系数据库经过更好的测试并且可能更稳定,如果单表关系数据库足够好,是否有充分的理由使用 NoSQL 数据库?

Vér*_*ace 15

不 - 单表关系数据库更类似于电子表格而不是 NoSQL 数据库。NoSQL 不是没有架构,而是拥有灵活的架构!

Wikipedia 当它说 NoSQL 时说得很好:

提供一种存储和检索数据的机制,该机制以关系数据库中使用的表格关系以外的方式建模。

这里的关键(请原谅双关语)词是modeled- 即有一个模型,它只是不是一个关系模型!

顺便说一句,非常值得阅读整篇文章 - 它详细且写得很好!

IBM 说:

需要强调的是,“NoSQL”中的“No”是“not only”的缩写,而不是实际的“No”一词。这种区别很重要,不仅因为许多 NoSQL 数据库支持 SQL 之类的查询,而且因为在微服务和多语言持久性的世界中,NoSQL 和关系数据库现在通常在单个应用程序中一起使用。

事实上,许多 NoSQL 系统(很难说“供应商”,因为其中许多系统都是开源的)正在争先恐后地(或已经争先恐后地)将 SQL 接口放在他们的系统之上,因为很多程序员都熟悉这种范式(而且它是多年来一直运行良好的一种)。

人们可以写整篇关于 NoSQL 与经典 RDBMS 的文章(就像我在大学时所做的那样),除了敦促您阅读该主题之外,我不会再沿着这条路走下去。

这是迷人的观看数据库生态圈的发展-新的SSD芯片技术,对我来说,最有趣的发展是近期重点LSM( Log Structured Merge tree),它被广泛应用于NoSQL系统和也NewSQL ones。恕我直言,这些 NewSQL 系统是未来的方向,我希望看到 Oracle、SQL Server 等。采用他们的许多范式(或者embrace and extend他们创造一个短语)。

同样,这是一项复杂的技术,可以编写 reams,但来自here

LSM 算法的核心是滚动合并过程:.... LSM 树将数据从更小、性能更高(但更昂贵)的存储级联到更大的性能较低(和更便宜)的存储中。

数据不是就地更新,而是“分块”并来自here

一旦内存树达到阈值大小,就会创建一个新的内存树并将旧树同步到磁盘。一旦写入磁盘,树是只读的,尽管它们在后台与其他磁盘树合并以降低读取成本。

你在你的问题中提到了 SQLite - 你可能会惊讶地发现(它让我感到惊讶)有一个Key-Value "version"SQLite 是在 2012 年到 2014 年之间开发的。来自here

从 SQLite4 中吸取的经验教训已合并到 SQLite3 中,该 SQLite3 将继续得到积极维护和开发。该存储库作为历史记录存在。目前没有计划恢复 SQLite4 的开发。

我会把最后一句话留给Brian AkerMySQL 的前架构总监,他展示了他对 NoSQL 的有趣看法,可在 YouTube 上找到here。我认为他的观点可以用他在那次演讲中展示的一幅漫画来最好地概括:

在此处输入图片说明

+1 一个有趣的问题(我希望不会被关闭!)欢迎来到论坛!


Mic*_*een 9

是的,您可以像使用 NoSQL 数据库一样使用单表关系数据库。你也可以用勺子来粉刷你的房子。

您必须按照预期的方式使用工具,否则您将同时与工具和试图使用该工具解决的问题作斗争。如果您想要规范化并且不存在数据异常,那么您可能会有很多表。如果您将所有逻辑实体类型推送到单个物理表中,您将拥有许多列(并且所有 DBMS 都有限制),其中大部分将为空,使查询成为一场噩梦,DRI 也是如此。您可以将所有这些值放入 JSON 或 XML 列中。如果所有粉碎都发生在您刚刚发明的键值存储的应用程序中。如果您希望 DBMS 查询它,您就有一个树解析器伪装成 SQL 解析器伪装成无模式解析器。无论如何谁需要性能。

现在,我的油漆勺在哪里。