假设你在编写一种网络应用程序,比如一个简单的图片分享网站,用户可以贡献内容。
有多少个充分的理由让你不选用面向对象数据库(如db4o)?
假设你在编写一种网络应用程序,比如一个简单的图片分享网站,用户可以贡献内容。
有多少个充分的理由让你不选用面向对象数据库(如db4o)?
如果你只需要通过对象访问数据,那么OODBMS更好。如果你的解决方案需要额外的数据通道(例如:临时查询、报告、其他需要访问数据但无法使用你的对象的应用程序),那么传统的RDBMS系统更好。
注意:OODBMS在这个领域已经取得了很大的进展。
我不知道你的计划有多大,但是招聘或借助经验丰富、技能娴熟的人员将影响我的决定,以及掌握关于DB所有内部和外部的广泛知识。
Oracle或MySQL都有缺陷,但是如果你遇到问题,很可能已经有其他100个人遇到过同样的问题并告诉你如何解决它。
这可能有些牵强,但是用 Joel 的话来说,要为成功做好规划。如果您的应用程序变得非常受欢迎,该怎么办?
例如,如果您将应用程序托管在自己的计算机上,但决定转向正式的托管站点或甚至服务器集群。他们支持对象数据库(OODB)和MySQL的机会有多大?
我只建议在应用程序设计真正,真正地重度面向对象,并且复杂性需要时才使用OODBMS。一个照片分享网站似乎不太重视OO方面,所以我不认为选择db4o有意义。
但是,如果你只是想通过一个宠物项目了解如何使用OODBMS的内部和外部,那么使用一个是可以的。
数据大小(如果我处理数百万行数据,我会坚持我所知道的)
报告(在规范化数据库中通常已经很困难了,在面向对象的数据库中更加糟糕)
专业知识/经验的可用性(关系型数据库明显有更多的拥护者)
大量的ETL(大多数人都使用平面文件导入和导出,除非你正在获取/发送XML,否则你只是在谈论普通的表格)
这些都不像是你的项目的障碍
就我个人而言,有数据的地方就需要报告。
没有面向对象数据库(OODBs)能够为您的数据提供适当的存储模型,以便您的报告应用程序可以使用。
当你只有一辆脚踏车时,需要的是速度。
场景包括数据捕获(例如日志记录),在事件之后,捕获的数据通常会在以后的阶段进行处理,并且可能会被分解为其对象组成部分。
也许你们也想查看这篇文章:
http://microsoft.apress.com/asptodayarchive/74063/using-an-object-oriented-d
Jim Paterson的文章:“在网站中使用OODB”
最好!