我搜索了一下 OODBMS 和 RDBMS 之间的区别。我几乎知道它们是什么。但是,我将如何决定哪一个更适合哪些应用程序。任何人都可以帮助我吗?
我对工厂管理的意思是:有生产瓶装、冷冻和其他食品的生产线。该应用程序管理从分配员工到生产线,将生产记录保存在系统中。哪种 dbms 更适合此类系统?
提前致谢。
我搜索了一下 OODBMS 和 RDBMS 之间的区别。我几乎知道它们是什么。但是,我将如何决定哪一个更适合哪些应用程序。任何人都可以帮助我吗?
我对工厂管理的意思是:有生产瓶装、冷冻和其他食品的生产线。该应用程序管理从分配员工到生产线,将生产记录保存在系统中。哪种 dbms 更适合此类系统?
提前致谢。
这是 Rick Grehan 的一篇很好的文章,描述了 ODBMS 有用的情况: http ://www.odbms.org/wp-content/uploads/2013/11/006.04-Grehan-When-to-Use-an-ODBMS- 2005.pdf
免责声明:这是一个“老顽固”的答案,来自一个在 OOP 成为主流之前编写了大量功能完善的会计、制造和其他代码的人。
话虽这么说...
工厂管理是经典的关系数据库的东西,它就是被发明出来的。经典关系应用程序的代码倾向于遵循非常可预测的模式,在从表中检索的行上进行大量循环,或者直接传递东西:将数据向上传递到 UI 或向下传递到数据库。如果您的数据库设计良好,那么您编写的商业逻辑将是那些循环或传递中的细节,但这两种模式将占主导地位。
另一方面,从这个“老顽固”的角度来看,OODMS 试图将功能完美且高效的 RDBMS 重铸为可以与类/对象一起使用的东西,而对已经证明自己的系统没有明显的收益几十年来工作得非常好。类与位于关系数据库之上的经典代码模式几乎没有关系。事实上,它们往往会使事情复杂化,并且很容易成为障碍。我并不是说不要使用 OOP 代码来处理数据库,只是说 OOP 是为不同类型的问题而发明的,这是数据库应用程序碰巧没有的问题。
选择 OODBMS 或 RDBMS 的决定并不取决于特定的应用程序,如工厂管理/自动化。这取决于许多标准,例如
1)编程范式- 如果您 [程序员] 选择使用 OO 编程语言进行可视化/实现,那么 OODBMS 适合将对象直接存储到数据库中,但最广泛的是关系型 DBMS 类型,因为它在商业上已经很成熟并具有良好的数学背景。
2)特定应用- 对于工厂自动化/管理,响应能力和快速访问非常重要。OODBMS 比 RDBMS 更快。如果您考虑进行 Web 开发,那么像 MySQL 这样的轻量级工具将非常适合。
3)趋势- 现在有从传统/结构到面向对象/组件的编程范式迅速。因此,在这种趋势下,OODBMS 最适合工厂管理等企业应用程序。
这取决于使用的应用层。如果它是一种更接近程序方式的简单方法[也可以有类],RDBMS 更合适。否则,如果您更倾向于严格的面向对象系统,则可以使用 OODBMS。
我通常在需要将它们集成到企业系统中的点上画出有用性的界限。如果您的项目不一定需要集成,ODBMS 通常更容易或在技术上更优越。如果您可以通过 Web 服务或“推/拉”集成到企业系统数据库中,那么您仍然可以使用 ODBMS,但可能存在反对它的政治压力。(较新的 ODBMS/RDBMS 复制,如 db4o 的 dRS 可能是一个不错的选择)但是如果您需要与遗留或企业数据存储紧密集成,那么您通常会出于某种原因被迫使用 RDBMS。
也就是说,您的个人生产线可能会从 ODBMS 中受益匪浅,ODBMS 擅长存储经常变化的复杂对象模型和模式,而编排系统可以遵循我之前的思路。
I've been using ODBMS for many years, and have been dreading the project which requires me to return to purely relational data management. Although recent improvements in ORM tooling have made relational much more pleasant to work with, the ORM+RDBMS solution still can't keep up with ODBMS systems in a few key areas (see the previously mentioned article on odbms.org).