历史上,什么使关系数据库流行?

时间:2010-03-03 12:16:04

标签: database

编辑我刚开始略读Codd着名的1970年论文,该论文启动了这一切,Oracle基于(A Relational Model of Data for Large Shared Data Banks [pdf]),并且惊讶地发现它似乎会回答这个问题。它讨论当时市场中的数据库(“层级”和“网络” - 如NoSQL?),是否需要独立于内部表示,以及如何应用数学“关系”的明确解释“到数据库。


历史上,关系数据库的哪些特性给了企业采用它带来了哪些好处,使其大获成功?

今天,使用RDB的原因有很多:它是标准的,产品是成熟的,调试的,功能齐全的,有供应商选择,有支持,有训练有素的劳动力等等。但为什么它变得如此受欢迎?

我听说“分层数据库”在关系数据库之前很流行 - 它们听起来像一个键值存储,其中值可以是另一组键值。如果是这样,那就类似于十年或两年前公布的面向对象数据库;还有XML /文档数据库和NoSQL。

也许 ACID交易(原子性等)?但这似乎并不是RDB特有的。

也许是因为关系数据库使您能够定义纯粹与数据相关的数据模式 - 独立于特定编程语言,应用程序版本(演化)或应用程序的目的(这使“阻抗不匹配”变得不可避免)但任何具有数据模式的数据库都具有此功能。

也许是因为关系模型在数学上是合理的?但这听起来并不能说服管理者采用它 - 这将带来什么商业利益。

也许是因为数学模型为您提供了一种方法,可以将数据库重新排列为不同的普通形式,以提供不同的性能特征,这些特性在数学上保证不会改变数据的含义?这似乎是合理的,我的单一教科书对此有很大的帮助,但这对我来说听起来并不具有实际的商业利益(也许我错过了一些东西)?

总结一下:历史上,是什么让关系模型在层次模型中如此果断地获胜?我也对RDB是否仍然具有一些特殊品质感兴趣,这些特质使其成为企业更好的实用选择(除了作为上述标准的好处之外)。

非常感谢你能否解释一下 - 我一直很好奇。

5 个答案:

答案 0 :(得分:6)

出于同样的原因,脚本语言很受欢迎。

您可以使用自己喜欢的文本编辑器进行查询,然后发布它,而无需考虑实际的物理架构。

它不是最快的型号,不是最可靠的型号 - 它只是最高效的型号。您可以在一小时内写出十倍的查询。

您可能希望在我的博客中阅读这篇文章,其中比较了最受欢迎的数据库模型:

答案 1 :(得分:4)

从物理表示中抽象出数据的逻辑表示的概念可能是Codd想法中改变游戏规则最多的方面。他显然是第一个完全意识到分离逻辑和物理问题的好处的人,因此他是第一个设计出名副其实的数据模型的人。通过描述基于关系的模型,没有导航链接或指针结构,他还创造了一些独特的强大,灵活和持久的相关性。

准确地说,必须说它是SQL模型而不是最终证明在商业上更成功的关系模型。 SQL离真正的关系数据模型或语言还有很长的路要走,即使没有Codd的想法激发它也不会产生。关系模型的创建者自然很失望,SQL而不是关系成为数据库标准。四十年后,我认为我们有充足的理由感到后悔Codd的关系模型没有得到DBMS软件更好的支持。

答案 2 :(得分:2)

据我所知,定义关系数据模型是规范化理论(众所周知的Codd第三范式),它可以轻松有效地存储和检索。接下来是标准查询语言(SQL),它允许在所有关系数据库系统中使用它。当时标准化肯定是缺乏的,这也使许多人感到有吸引力。

答案 3 :(得分:2)

我相信没有一个答案确实能够解决它,因为你对它的历史方面感兴趣。

如果我说出一个理由我会说Quassnoi很接近,但SQL不仅仅是任何一种语言 - 它有一个很棒的功能,在70年代并不常见:

  • 它是声明性的,它描述了您想要获得的内容并且没有规定如何执行此操作

我认为不可能夸大这一点。

当然,关系模型也是因子(与上述相关)

  • 并非所有具有架构的数据库都只是关于数据;分层和网络数据库也是关于如何获取数据,它们的结构决定了访问数据的最有效方法,因此结构影响你将如何建模问题(换句话说,建模过程受到方式的影响应用程序将使用它;这会导致另一个可能需要使用IMS的应用程序处于严重不利的位置,或者应用程序中的某些更改不需要更改数据库设计以实现良好性能 - 例如需要按一些新列排序)

注意:关于上述一些意图,SQL和'R'DBMS没有完全交付(和/或其他模型以某种方式克服了他们的问题),但这些是最初的意图,并考虑到SQL过去的稳定性~40几年(这里是来自1974的IBM论文的链接)或者它也没有这么糟糕,糟糕的工作。

here

也引用了这句话
  

“泰德的基本想法是这样的   数据项之间的关系   应该基于项目的价值,   而不是单独指定   链接或嵌套。这个概念   大大简化了规范   查询和允许前所未有的   灵活地利用现有数据   以新的方式设置,“唐说   Chamberlin,SQL的共同发明者,   行业标准语言   查询关系数据库,和   Almaden的研究人员。 “他   相信计算机用户应该是   能够工作更多   自然语言水平而不是   关注细节的地方   或者如何存储数据。“

     

1995年IBM早期重聚   关系数据库科学家,   张伯伦回忆起顿悟   正如他第一次听到Codd描述他的那样   内部关系模型   研讨会。

     

“Codd有一堆公平   复杂的询问,“Chamberlin说。   “因为我一直在研究CODASYL   (用于查询的语言   导航数据库),我可以   想象一下这些查询会有多少   在CODASYL代表   五页长的节目   这将导航通过这个   迷宫的指针和东西。科德   会把它们写下来   单行。 ......(嘿)不是   一点都不复杂。我说,“哇。”   这是一种转换   经验对我而言。我明白了   关系的事情是关于事后的   该“。

我似乎记得有关乞讨SQL的有趣访谈的记录,但无法追踪它。

答案 4 :(得分:1)

一个关键是自包含的产品 - 您不再需要手动定义和维护您的密钥文件(索引)以及更轻松地更改数据模型的能力。将其与基于SET的结构相结合,使其成为令人信服的产品组合。结合使用SQL语言来返回数据,与主要与COBOL语言相关的传统ISAM数据结构相比,这是一个双赢的局面。