问关系阵营和“现实世界”数据库开发

EN

多年来，我看到了许多关于OODs应该如何“很快”超越关系数据库的讨论；关系模型是过去的方式；来自巨大安装基础的惯性(嗯……遗留问题)是阻碍OODs发展的原因。“‘足够好’的实现最终问世并成功淘汰RDBMS只是个时间问题。”

我无论如何都不是专家；但我已经考虑过很多次了，我逐渐相信这些观点完全没有抓住要点。

在大多数“现实世界”场景中，最重要的是data。

编程技术、工具和语言在变化；技术在发展。公司的“语音应答系统”变得流行起来，然后几乎消失在“网络”的阴影之下。应用程序来来去去；有些很好，有些不是很好；有些是关键的，有些只是方便的；有些持续3个月，有些持续30年。但归根结底，供给所有这些应用程序的信息是系统的核心，必须在时尚的波动中幸存下来。数据保持为。

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

想想看: SQL数据库为我们提供了一个独立的，(主要)标准化的存储库，具有几十年的可靠记录，并且可以用根本上不过时的函数式语言随时访问！对于您最有价值的组件来说，这是一个非常值得信任的地方。

任何将优先级放在编程工具、环境或应用程序中，而不是将数据保存在模糊存储中的方法--任何将应用程序技术与数据绑定得太紧密的东西--都很可能会被淘汰。

这并不是说我相信世界上的所有东西都必须放入SQL表中。类似OOD的解决方案也有一席之地，有很大的潜力。但您需要关注“应用程序”为王、“数据”为辅的地方:游戏、一次性应用程序和工具、保存非关键数据的系统，或者在应用程序的预期寿命之外没有长期价值的数据。

特别是，我认为使用寿命有限(最多几年)的系统是OOD类技术的主要候选者。另一方面，当处理任何有一天必须将数据“移交”给其继任者的工作时，我会非常谨慎，除非是一个老式的RDBMS。

简而言之，它从来不是关于“应用程序”的；它总是与“数据”有关。是关于“数据”的。

面向对象的数据库是一个矛盾的修饰法。你越想创建一个OO数据库，你就越会陷入关系型世界。在我看来，这只是一种炒作。请注意，ORM不是OO数据库。数据集也不是。我以前听过这种说法，所以我这么说只是为了把事情搞清楚。

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