2008-09-27 40 views
6

超过十年,因为日期的首次出版,并通过更多达尔文的"The Third Manifesto" 1995年关系阵营和“现实世界”数据库开发

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

回答

1

我们正在看到一些方法,即对象建模技术可以用于管理数据。我们有Linq和NHibernate,它允许我们将数据库中的数据映射到代码中的对象。然而。我认为我们离真正面向对象的数据库还有很长的路要走。我不知道我们会永远。虽然使用“对象”具有优势,但使用关系数据模型将数据视为集合具有很多优点。

1

到目前为止,似乎已经走出了OODBMSs不会有尽可能广泛的采用一些想要他们,原因很简单:只OODBMSs解决OOP开发者的关注,而不是其他人,这包括DBA,分析师,MIS专业人员以及大量不是面向对象的开发人员,而是“数据驱动”。

如此说来,企业数据的大量残留在RDBMS中,以类似的方式企业数据的大量也保持在COBOL/CICS供电系统。

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

+0

确实如此,不要忘记列表中的用户,审计员,senoir经理等。我的数据库存储了我工作的公司的整个生命线。 – HLGEM 2008-09-28 21:50:28

0

我一直处理的数据集太大认真考虑渲染数据包含所有的信息和方法来访问数据元素类的经典的“对象”的模式/操纵它们。

但是我发现了一个简单的与.NET数据集的妥协模型。由于它们“自我缓冲”到磁盘,它们对于处理可能会或可能不适合内存的大量数据非常有用 - 所以我将它们用于我的“对象集合”。

然后所有包含“业务”的对象应用程序的类只是在一个包含自己的信息和所有的类简单地从记录集解析方法,在数据集中的记录的引用。

Works的查询返回1个结果一百万 - 和类模式很容易复制 - 因为基本上所有的类的内部数据变量只是在记录的字段。

1

在业务数据处理中,关系模型是稳固根深蒂固的,无法删除。它是中心因素,通常会被滥用于不适当的事情。人们会使用(滥用)关系数据库作为可靠的消息队列,因为 - 他们将每个问题视为数据库问题。

关系模型是每个业务流程的许多(几乎所有)商业产品的支柱。很难找到任何不具有根本关系的东西。事实上,在许多情况下,产品与数据库密切配合。 Oracle的财务,微软的Dynamics会计等。

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

目前,关系数据库不言而喻。每个人都会问“哪个数据库引擎”,这样他们就可以权衡Oracle与IBM,微软与MySQL之间的争论。没有人会问“数据模型会是什么?对象或关系?”

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

4

面向对象数据库是一个矛盾。无论如何,越是尝试创建面向对象的数据库,越是在关系世界中最终结束。在我看来,他们只是炒作。 请注意,ORM的不是OO数据库。数据集也不是。我以前听说过这个论点,所以我只是想说清楚一下。

+0

这就是第三个宣言的要点,我认为:真正的关系数据库系统(不是我们今天所拥有的)不需要任何OR映射,它根据定义支持对象。 – Constantin 2008-09-28 11:13:01

10

这些年来我见过很多关于OOD如何超越关系数据库的讨论。关系模型是过去的方式;从巨大的安装基础(电阻... 传统)的惯性是妨碍OOD进展。 “只要一个'足够好的'实现终于出来并成功地破坏RDBMS,只是时间问题。”

我不是专家,但我已经想了很多次了,我认为这些观点完全错过了这一点。

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

编程技巧,工具和语言的变化;技术发展。企业“语音应答系统”变得风靡一时,然后几乎消失在“网络”的阴影之后。应用程序来来去去;其中一些很好,一些不太好;一些关键的,有些仅仅是方便;一些最后3个月,一些最后的30年。但在一天结束时,提供所有这些应用程序的信息是系统的心脏,并且必须经受住时尚的波动。 数据保留

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

想想看:在特定的SQL数据库给我们一个自由站立,(大部分)有几十年历史的记录证明标准库,并可以用什么,远未过时的,本质上是功能随时随地访问语言!这是一个相当不错的地方去信任你最有价值的组件。

任何将编程工具,环境或应用程序的优先级放在将数据保存在模糊存储区中的任何方法 - 任何将应用程序技术与数据绑定得太紧密的东西都可能会下降在路边。

不是说我相信世界上的一切都必须进入SQL表格。类似OOD的解决方案也有一席之地,并且具有很大的潜力。但是您需要查看“应用程序”为王,“数据”为次要的地方:游戏,一次性应用程序和工具,持有不重要数据或过去没有长期价值的数据的系统应用程序的预期寿命。

特别是,我认为具有有限使用寿命(最多几年)的系统是类OOD技术的主要候选者。另一方面,当有一天需要将数据“交给”其后继者的任何事情时,除了一个古老的RDBMS之外,我会非常遗憾的。

把它放在一个健全的字节里,它从来不是关于“应用程序”的;它的总是一直关于“数据”。

+0

好说!谢谢, – Sklivvz 2008-09-28 17:36:37

0

否 通过云计算的出现,支持者不一定以关系方式存储数据,最近才发生了唯一明显的变化。