【发布时间】:2010-09-13 15:32:13
【问题描述】:
自 1995 年 Date 和 Darwen 的 "The Third Manifesto" 首次发布以来,已经过去了十多年。
关系学派在当今数据库世界中的位置是什么? 是否有任何证据表明 Manifesto 的想法改变了主流软件开发和数据管理实践?他们是否催生了新的数据管理产品?这些产品在商业上是否成功?
【问题讨论】:
标签: database-design relational-database relational
自 1995 年 Date 和 Darwen 的 "The Third Manifesto" 首次发布以来,已经过去了十多年。
关系学派在当今数据库世界中的位置是什么? 是否有任何证据表明 Manifesto 的想法改变了主流软件开发和数据管理实践?他们是否催生了新的数据管理产品?这些产品在商业上是否成功?
【问题讨论】:
标签: database-design relational-database relational
多年来,我看到很多关于 OOD 应该如何“很快”超越关系数据库的讨论;关系模型是过去的方式;来自庞大安装基础的惯性(嗯...legacy)阻碍了 OOD 的进展。 “‘足够好’的实现最终出现并成功取代 RDBMS 只是时间问题”。
无论如何,我都不是专家;但我想了很多次,我开始相信这些观点完全没有抓住重点。
在大多数“现实世界”场景中,重要的、唯一重要的是数据。
编程技术、工具和语言发生变化;技术不断发展。企业“语音应答系统”风靡一时,然后几乎消失在“网络”的阴影后面。申请来来去去;其中一些很好,一些则不然;有些很关键,有些只是方便;有的持续 3 个月,有的持续 3 年。但归根结底,为所有这些应用程序提供信息的信息是系统的心脏,必须经受住时尚的波动。 数据保留。
因此,“系统”的核心必须围绕一个目标发展:保存和保护数据。
想一想:SQL 数据库尤其为我们提供了一个独立的、(大部分)标准化的存储库,具有数十年的成熟记录,并且可以随时访问,并且远未过时,本质上是一个功能性的 语言!对于您最有价值的组件来说,这是一个值得信赖的好地方。
任何将优先级放在编程工具、环境或应用程序上,而以将数据保存在隐蔽存储中为代价的方法——任何将应用程序技术与数据绑定得太紧密的方法,都可能会失败路边。
并不是说我相信世界上的一切都必须进入一个 SQL 表。类似 OOD 的解决方案也有一席之地,而且潜力巨大。但是您需要查看“应用程序”为王,“数据”为次要的地方:游戏、一次性应用程序和工具、保存非关键数据或过去没有长期价值的数据的系统应用程序的预期寿命。
特别是,我认为使用寿命有限(最多几年)的系统是类 OOD 技术的主要候选者。另一方面,当处理任何必须有一天将数据“移交”给其继任者的事情时,我会非常警惕除了旧的 RDBMS 之外的任何事情。
把它放在一个合理的字节中,从来都不是关于“应用程序”的;它一直都是关于“数据”的。
【讨论】:
面向对象的数据库是矛盾的。您尝试创建 OO 数据库的次数越多,您最终进入关系世界的次数就越多。在我看来,它们只是一种炒作。 请注意,ORM 不是 OO 数据库。数据集也不是。我以前听过这个论点,所以我说它只是为了说明问题。
【讨论】:
我们看到对象建模在管理我们的数据方面正在发挥作用。我们有 Linq 和 NHibernate,它们允许我们将数据库中的数据映射到代码中的对象。然而。我认为我们距离真正的面向对象数据库还有很长的路要走。我不确定我们会不会。虽然使用“对象”有其优势,但使用关系数据模型将数据视为集合具有很多优势。
【讨论】:
到目前为止,出现的 OODBMS 似乎并没有像某些人希望的那样得到广泛采用,原因很简单:OODBMS 只解决了 OOP 开发人员的问题,而不是其他所有人 em>,其中包括 DBA、分析师、MIS 专业人员以及大量不面向对象而是“数据驱动”的开发人员。
话虽如此,大量企业数据仍保留在 RDBMS 中,就像大量企业数据也保留在 COBOL/CICS 驱动的系统中一样。
至于事实,您可以用谷歌搜索数小时的统计数据,但找不到任何数据。您会发现 Oracle 与 MS SQL Server 与 MySQL/PostGre/其他开源 RDBMS 采用统计数据之间的对比,而像 db4o 这样的 OODBMS 在很大程度上被忽略了。
【讨论】:
在业务数据处理中,关系模型根深蒂固,无法移除。它是核心,并且经常被过度用于不恰当的事情。人们将使用(滥用)关系数据库作为可靠的消息队列,因为——嗯——他们将每个问题都视为数据库问题。
关系模型是每个业务流程的许多(几乎所有)商业产品的支柱。很难找到根本不相关的东西。事实上,在许多情况下,产品与数据库密切相关。 Oracle 的 Financials、Microsoft 的 Dynamics 会计等。
在可预见的未来,关系数据存储将成为业务数据处理的主要存储。
目前,关系数据库不言而喻。每个人都问“哪个数据库引擎”,以便他们可以权衡 Oracle 与 IBM 与 Microsoft 与 MySQL 的辩论。没有人问“数据模型是什么?对象还是关系?”
ORM 将继续取得进展。面向对象的编程将继续增长,导致越来越多的 ORM。打破这个盒子很难——几乎是不可能的——因为业务 IT 关注的是稳定性,而不是创新。他们的目标几乎总是“保持灯亮”。这意味着拒绝更改,直到供应商停业或终止对产品的支持。
【讨论】:
没有 唯一显着的变化是最近通过云计算的出现而出现的,其中支持者不一定以关系方式存储数据。
【讨论】:
我一直在处理太大的数据集,无法认真考虑将数据呈现为类的经典“对象”模型,其中数据元素包含所有信息和访问/操作它们的方法。
然而,我发现了一个简单的 .NET 数据集折衷模型。由于它们“自我缓冲”到磁盘,因此它们非常适合处理可能适合或不适合内存的数据块 - 所以我将它们用于我的“对象集合”。
然后,构成应用程序“业务”对象的所有类都简单地引用了包含其信息的数据集中的记录,并且该类的所有方法都简单地从记录集中解析。
适用于将 1 个结果返回到 100 万个结果的查询 - 并且类模型很容易复制 - 因为基本上所有类内部数据变量都只是记录集上的字段。
【讨论】: