任何人都可以想到一些很好的理由不使用面向对象的DBMS来支持网站吗？

题

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

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

解决方案

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

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

其他提示

我不知道你的计划有多大，但是经验丰富和技术熟练的人员可以聘用（或只是伸出援助之手）会影响我的决定，以及一般的大量知识。 DB的来龙去脉。

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

我想说的是，如果你正在考虑像db4o这样的东西，他们似乎没有为网站供电的企业示例，并且主要用于嵌入式应用程序。

请参阅我的其他帖子。（使用db4o的示例网站）

技术上没有什么在这里，只是采用它似乎。但是，为了提高开发速度，维护和设计灵活性，OODB是无与伦比的。

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

这有点紧张，但是为了解释乔尔的帖子，计划成功。如果你的应用真的很受欢迎怎么办？

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

如果您的应用程序设计真的非常，面向对象，并且复杂性需要它，我建议您选择OODBMS。在OO方面，照片共享网站听起来并不是很重，所以我没有看到db4o的重点。

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

有关使用db4o进行报告，请参阅：

另一个好理由是相对长寿。 db40是一款出色的产品，但它的用户群很小，并且不太可能比SQL Server更耐用。

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

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

报告（在标准化数据库中通常很难，在OO数据库中更糟糕）

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

大量的ETL（大多数人在平面文件中导入和导出，除非你得到/发送XML，你说的是普通的老桌子）

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

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

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

“在网站中使用OODB”作者：Jim Paterson

最佳！

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

我的个人意见，有数据......有报道。

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

许可以下： CC-BY-SA 和归因

任何人都可以想到一些很好的理由*不*使用面向对象的DBMS来支持网站吗？