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

Question

自1995年首次出版约翰和达文"The Third Manifesto"以来已过去十多年。

今天的数据库世界中关系学派的地方是什么？ 有没有证据表明Manifesto的想法改变了主流软件开发和数据管理实践？他们是否催化了新数据管理产品的创建？这些产品在商业上是否成功？

Answer 1

多年来我看到很多关于OOD如何“很快”超越关系数据库的讨论;关系模型是过去的方式;从庞大的安装基础（ehm ... 遗产）的惯性是阻碍OOD进展的因素。 “在'足够好'的实施最终出现并成功废除RDBMS之前，这只是一个时间问题。”

我不是一个专家;但我已经多次考虑过这个问题，而且我开始相信这些观点完全忽视了这一点。

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

编程技术，工具和语言发生变化;技术在发展。企业“语音响应系统”成为风靡一时，然后几乎消失在“网络”的阴影背后。应用程序来来去去;其中一些是好的，一些不是那么多;有些批评，有些只是方便;过去3个月，过去30年。但最终，提供所有这些应用程序的信息是系统的 heart ，并且必须在时尚的摇摆中存活下来。 数据保持。

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

考虑一下：SQL数据库特别为我们提供了一个独立的（大多数）标准化存储库，其中包含了数十年的成熟记录，并且可以随时访问，远非过时，基本上是功能语言！对于您最有价值的组件来说，这是一个值得信赖的好地方。

任何将优先级放在编程工具，环境或应用程序中的方法都会牺牲在隐藏的商店中保存数据 - 任何将应用程序技术与数据紧密联系在一起的东西都可能会脱落路边。

不是说我相信世界上的一切都必须进入SQL表。类似OOD的解决方案也有一席之地，并且具有很大的潜力。但是你需要查看“应用程序”是王者的地方，“数据”是次要的：游戏，一次性应用程序和工具，包含非关键数据的系统或没有长期价值的数据申请的预期寿命。

特别是，我认为使用寿命有限（最多几年）的系统是OOD类技术的主要候选者。另一方面，当处理任何有一天必须将数据“移交”给它的继承者的任何东西时，除了古老的RDBMS之外，我会非常谨慎。

要把它放在一个声音字节中，它从来就不是关于“应用程序”的; 总是关于“数据”。

Answer 2

面向对象的数据库是矛盾的。你尝试建立OO数据库越多，你在关系世界中的结果就越多。在我看来，他们只是一个炒作。 请注意，ORM不是OO数据库。数据集也不是。我之前听过这个论点，所以我只是为了说清楚。

Answer 3

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

Answer 4

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

话虽如此，大量的企业数据仍然存在于RDBMS中，类似于大量企业数据也保留在COBOL / CICS驱动的系统中。

至于事实，谷歌可以花几个小时来查找统计数据但你找不到任何数据。您所发现的只有Oracle与MS SQL Server与MySQL / PostGre /其他开源RDBMS采用统计数据相互比较，而像db4o这样的OODBMS在很大程度上被忽略了。

Answer 5

在业务数据处理中，关系模型是根深蒂固的，无法删除。它是核心，通常高度过度使用不适当的东西。人们将使用（滥用）关系数据库作为可靠的消息队列，因为 - 他们将每个问题视为数据库问题。

关系模型是每个业务流程中许多（几乎所有）商业产品的支柱。很难找到任何基本没有关系的东西。实际上，在许多情况下，产品与数据库紧密结合。 Oracle的财务，微软的动态会计等

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

目前，关系数据库不言而喻。每个人都询问“哪个数据库引擎”，以便他们可以权衡Oracle与IBM与Microsoft与MySQL的争论。没有人问“数据模型是什么？对象或关系？”

ORM将继续取得进展。面向对象的编程将继续增长，导致越来越多的ORM。打破这个框架很难 - 几乎不可能 - 因为业务IT专注于稳定性而非创新。他们的目标几乎总是“保持亮灯”。这意味着拒绝变更，直到供应商停止营业或终止对产品的支持为止。

Answer 6

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

然而，我找到了一个包含.NET数据集的简单折衷模型。由于它们“自缓冲”到磁盘，它们非常适合处理可能适合或不适合内存的数据块 - 所以我将它们用于我的“对象集合”。

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

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

Answer 7

没有 最近唯一明显的变化是通过云计算的出现，其中支持者不一定以关系方式存储数据。