自1995 年伊达和达尔文的《第三宣言》首次出版以来,已经过去了十多年。
关系学派在当今数据库世界中的位置是什么?是否有任何证据表明 Manifesto 的想法改变了主流软件开发和数据管理实践?他们是否催生了新的数据管理产品?这些产品在商业上是否成功?
自1995 年伊达和达尔文的《第三宣言》首次出版以来,已经过去了十多年。
关系学派在当今数据库世界中的位置是什么?是否有任何证据表明 Manifesto 的想法改变了主流软件开发和数据管理实践?他们是否催生了新的数据管理产品?这些产品在商业上是否成功?
多年来,我看到很多关于 OOD 应该如何“很快”超越关系数据库的讨论;关系模型是过去的方式;来自庞大安装基础的惯性(嗯……遗留)阻碍了 OOD 的进展。“‘足够好’的实现最终出现并成功取代 RDBMS 只是时间问题”。
无论如何,我都不是专家。但是我想了很多次,我开始相信这些观点完全没有抓住重点。
在大多数“现实世界”场景中,最重要的、唯一重要的就是数据。
编程技术、工具和语言发生变化;技术不断发展。企业“语音应答系统”风靡一时,然后几乎消失在“网络”的阴影后面。申请来来去去;其中一些很好,一些则不然;有些很关键,有些只是方便;有的持续 3 个月,有的持续 3 年。但归根结底,为所有这些应用程序提供信息的信息是系统的核心,必须在时尚的波动中幸存下来。数据保持不变。
因此,“系统”的核心必须围绕一个目标发展:保存和保护数据。
想一想:特别是 SQL 数据库为我们提供了一个独立的(大部分)标准化存储库,具有数十年的历史证明记录,并且可以随时使用远未过时的函数式语言访问!对于您最有价值的组件来说,这是一个值得信赖的好地方。
任何将优先级放在编程工具、环境或应用程序上,而以将数据保存在模糊存储中为代价的方法——任何将应用程序技术与数据绑定得太紧密的方法,都可能会被淘汰——边。
并不是说我相信世界上的一切都必须进入一个 SQL 表。类似 OOD 的解决方案也有一席之地,而且潜力巨大。但是您需要查看“应用程序”为王,“数据”为次要的地方:游戏、一次性应用程序和工具、保存非关键数据或过去没有长期价值的数据的系统应用程序的预期寿命。
特别是,我认为使用寿命有限(最多几年)的系统是类 OOD 技术的主要候选者。另一方面,当处理任何必须有一天将数据“移交”给其继任者的事情时,我会非常怀疑除了旧的 RDBMS 之外的任何事情。
简而言之,它从来都不是关于“应用程序”的;它一直是关于“数据”的。
面向对象的数据库是矛盾的。您尝试创建 OO 数据库的次数越多,您最终进入关系世界的次数就越多。在我看来,它们只是一种炒作。请注意,ORM 不是 OO 数据库。数据集也不是。我以前听过这个论点,所以我说它只是为了让事情清楚。
我们正在看到对象建模在管理数据方面的一些作用。我们有 Linq 和 NHibernate,它们允许我们将数据库中的数据映射到代码中的对象。然而。我认为我们距离真正的面向对象数据库还有很长的路要走。我不确定我们会不会。虽然使用“对象”有其优势,但使用关系数据模型将数据视为集合具有很多优势。
到目前为止,出现的 OODBMS 似乎并没有像某些人希望的那样被广泛采用,原因很简单:OODBMS 只解决 OOP 开发人员的问题,而不是其他所有人,包括 DBA、分析师、MIS专业人士,以及大量不是面向对象而是“数据驱动”的开发人员。
话虽如此,大量企业数据仍保留在 RDBMS 中,就像大量企业数据也保留在 COBOL/CICS 驱动的系统中一样。
至于事实,你可以谷歌几个小时来寻找统计数据,但你什么也找不到。您会发现 Oracle 与 MS SQL Server 与 MySQL/PostGre/其他开源 RDBMS 采用统计数据之间的对比,而像 db4o 这样的 OODBMS 在很大程度上被忽略了。
In business data processing, the relational model is firmly entrenched, and cannot be removed. It is central and is often highly overused for inappropriate things. Folks will use (abuse) a relational database as a reliable message queue because -- well -- they see every problem as a database problem.
The relational model is the backbone of many (almost all) commercial products for every business process. It's hard to find anything that's not fundamentally relational. Indeed, in many cases, the products are closely aligned with the database. Oracle's Financials, Microsoft's Dynamics accounting, etc.
For the foreseeable future, relational data stores will be the primary storage for business data processing.
Currently, relational databases go without saying. Everyone asks "which database engine" so they can weigh in on the Oracle vs. IBM vs. Microsoft vs. MySQL debate. No one asks "what will the data model be? Object or Relational?"
ORM will continue to make inroads. Object-Oriented programming will continue to grow, leading to more and more ORM. Breaking out of this box is hard -- nearly impossible -- because business IT is focused on stability, not innovation. Their goal is almost always "Keep The Lights On". That means to refuse change until it is forced on them by a vendor going out of business or ending support for a product.
我一直在处理太大的数据集,无法认真考虑将数据呈现为类的经典“对象”模型,其中数据元素包含所有信息和访问/操作它们的方法。
然而,我发现了一个带有 .NET 数据集的简单折衷模型。由于它们“自我缓冲”到磁盘,因此它们非常适合处理可能适合或不适合内存的数据块 - 所以我将它们用于我的“对象集合”。
然后,构成应用程序的“业务”对象的所有类都简单地引用数据集中包含其信息的记录,并且该类的所有方法都简单地从记录集中解析。
适用于将 1 个结果返回到 100 万个结果的查询——并且类模型很容易复制——因为基本上所有类内部数据变量都只是记录集上的字段。
否 唯一显着的变化是最近通过云计算的出现而出现的,在这种情况下,支持者不必以关系方式存储数据。