Database design 关系阵营和；“真实世界”；数据库开发

自1995年Date's和Darwen's第一次出版以来，十多年过去了

关系学派在当今数据库世界中的地位是什么？

---

有没有证据表明宣言的思想改变了主流软件开发和数据管理实践？它们是否促进了新数据管理产品的开发？这些产品在商业上成功了吗？

我们看到了对象建模在管理数据方面的一些方法。我们有Linq和NHibernate，它们允许我们将数据库中的数据映射到代码中的对象。然而。我认为我们离真正的面向对象数据库还有很长的路要走。我不确定我们会不会。虽然使用“对象”有它的优点，但使用关系数据模型将数据视为集合有很多优点。

到目前为止，已经问世的OODBMS似乎没有像一些人所希望的那样被广泛采用，原因很简单：OODBMS只解决OOP开发人员的问题，而不是其他所有人的问题，其中包括DBA、分析师、MIS专业人士，以及大量不是面向对象而是“数据驱动”的开发人员

话虽如此，大量企业数据仍保留在RDBMS中，其方式与大量企业数据也保留在COBOL/CICS系统中的方式类似

---

至于事实，你可以在谷歌上搜索数小时来寻找统计数据，但你找不到任何数据。所有你会发现的是Oracle与MS SQL Server对MySQL/PrgRe/其他开源RDBMS采用的统计数据相互关联，而像DB4O这样的OODBMSs在很大程度上被忽略了。

< P>我总是处理太大的数据集而不能认真地考虑经典的“对象”。将数据呈现为类的模型，数据元素包含所有信息和访问/操作这些信息的方法

然而，我发现了一个简单的折衷模型，它使用.NET数据集。因为它们可以“自缓冲”到磁盘，所以它们非常适合处理内存中可能适合也可能不适合的数据块，所以我将它们用于“对象集合”

然后，构成应用程序的“业务”对象的所有类只需引用数据集中包含其信息的记录，该类的所有方法只需从记录集中解析

---

适用于将1个结果返回到100万的查询—类模型非常容易复制—因为基本上所有类内部数据变量都只是记录集上的字段。

在业务数据处理中，关系模型是牢固的，无法删除。它是核心，经常被过度用于不恰当的事情。人们会使用（滥用）关系数据库作为可靠的消息队列，因为——嗯——他们把每个问题都看作是数据库问题

关系模型是每个业务流程的许多（几乎所有）商业产品的支柱。很难找到根本不相关的东西。事实上，在许多情况下，产品都与数据库密切相关。甲骨文的财务，微软的动态会计等

在可预见的未来，关系数据存储将成为业务数据处理的主要存储

目前，关系数据库不言而喻。每个人都会问“哪个数据库引擎”，这样他们就可以在Oracle与IBM、Microsoft与MySQL的辩论中发言。没有人会问“数据模型是什么？对象还是关系？”

---

ORM将继续取得进展。面向对象编程将继续发展，导致越来越多的ORM。打破这个框框很难——几乎不可能——因为商业IT关注的是稳定性，而不是创新。他们的目标几乎总是“开灯”。这意味着拒绝更改，直到供应商被迫停业或停止对产品的支持为止。

面向对象数据库是一种矛盾修饰法。你越是尝试创建一个OO数据库，你就越会最终进入关系世界。在我看来，它们只是一种炒作。

---

请注意，ORM不是OO数据库。数据集也是如此。我以前听过这种说法，所以我这么说只是想澄清一下。

多年来，我看到了很多关于OOD如何“在短时间内”取代关系数据库的讨论；关系模式是过去的方式；巨大的安装基础（ehm…遗留）的惯性阻碍了OOD的发展。“一个‘足够好’的实现最终出现并成功地取代RDBMS只是时间问题”

我根本不是专家；但是我想了很多次，我开始相信这些观点完全没有抓住要点

在大多数“现实世界”场景中，最重要、唯一重要的是数据

编程技术、工具和语言的变化；技术在发展。企业“语音响应系统”风靡一时，然后几乎消失在“网络”的阴影之下。申请来来往往；有的好，有的不怎么样；有些批评，有些只是方便；有些能持续3个月，有些能持续30年。但归根结底，为所有这些应用程序提供信息的信息是系统的核心，必须经受住时尚的波动数据保持不变

因此，“系统”的核心必须围绕一个目标发展：保存和保护数据

想想看：特别是SQL数据库，它为我们提供了一个独立的（主要是）标准化的存储库，具有数十年的经验证的记录，并且可以随时使用基本上不是过时的功能性语言进行访问！对于您最有价值的组件来说，这是一个值得信赖的好地方

任何将优先级放在编程工具、环境或应用程序中，而以将数据保存在隐藏存储中为代价的方法