web-applications - 谁能想到一些充分的理由不使用面向对象的 DBMS 来支持网站？

Question

假设您正在编写某种 Web 应用程序。人们可以贡献内容的地方，例如一个简单的照片共享网站。

您能想到多少不使用面向对象数据库（例如 db4o）的充分理由？

score 7 · Accepted Answer

如果您只需要通过对象访问数据，则 OODBMS 会更好。如果您的解决方案需要额外的数据路径（例如，即席查询、报告、其他需要数据访问但不能使用您的对象的应用程序），那么传统的 RDBMS 系统会更好。

注意：OODBMS 在这方面做了很多改进。

score 4 · Accepted Answer

我不知道您的计划有多大，但是是否有经验丰富的技术人员可以雇用（或只是帮忙）会影响我的决定，以及关于所有插件的大量知识和数据库外。

Oracle 或 MySQL 有其缺陷，但如果您遇到问题，则很有可能有 100 个人有同样的问题，并且可以告诉您如何解决它。

score 4 · Accepted Answer

我想说的是，如果您正在考虑类似 db4o 的东西，它们似乎没有为网站提供动力的企业示例，并且主要用于嵌入式应用程序。

请参阅我的另一篇文章。（使用 db4o 的示例网站）

这里没有技术上的障碍，似乎只是采用。然而，就开发速度、维护和设计灵活性而言，OODB 是无与伦比的。

如果需要，可以通过与关系后端同步来完成繁重的报告等，我知道 db4o 支持

score 3 · Accepted Answer

这有点牵强，但套用 Joel 的帖子，为成功做好计划。如果您的应用程序变得非常流行怎么办？

例如，如果您在自己的机器上托管应用程序，但决定转到正式的托管站点，甚至是服务器场，该怎么办。他们支持 OODB 与 MySQL 的可能性有多大？

score 2 · Accepted Answer

如果您的应用程序设计非常非常非常面向对象，并且复杂性提出了对它的需求，我只会推荐使用 OODBMS。照片共享站点在 OO 方面听起来并不重，所以我看不出选择 db4o 的意义。

但是，如果您真的只是想从一个宠物项目中了解使用 OODBMS 的细节，那么使用它就可以了。

score 1 · Accepted Answer

另一个很好的理由是相对长寿。db40 是一款出色的产品，但它的用户群很小，而且它的寿命不太可能比 SQL Server 之类的东西长。

当然，我也曾经说过 Java 无法生存。

score 1 · Accepted Answer

数据大小（如果我要处理数百万行，我会坚持我所知道的）

报告（在规范化数据库中通常足够困难，在 OO 数据库中更糟）

专业知识/经验的可用性（RDBMS 显然有更多的追随者）

大量 ETL（大多数人在平面文件中导入和导出，除非您正在获取/发送 XML，否则您说的是普通的旧表）

这些听起来都不是您项目的障碍

score 0 · Accepted Answer

我个人的看法，哪里有数据……哪里有报告。

没有 OODB 会为您的数据提供适当的存储模型以供您的报告应用程序使用。

score 0 · Accepted Answer

当你只有一辆脚踏车时，你需要速度。场景包括数据捕获（例如日志记录），在事件发生后，捕获的数据通常在稍后阶段进行处理，并且无论如何都可能分解为其对象组成部分。

score 0 · Accepted Answer

也许你们也想查看这篇文章：

Jim Paterson 的“在网站中使用 OODB”

最好的！

score 0 · Accepted Answer

对于具有适度数据需求的复杂应用程序，您无法击败 GLASS（Gemstone、Seaside 和 Smalltalk）。报告绝对是您想要在 Smalltalk 中做 OO 的事情。

web-applications - 谁能想到一些充分的理由*不*使用面向对象的 DBMS 来支持网站？