OODBMS - RDBMS 区别以及哪一种适合工厂管理系统
我搜索了一下 OODBMS 和 RDBMS 之间的差异。我几乎知道它们是什么。但是，我将如何决定哪一个更适合哪些应用程序。有人可以帮我吗？
我所说的工厂管理是：有生产瓶装、冷冻和其他食品的生产线。该应用程序从分配员工到生产线上进行管理，以将生产记录保存在系统中。哪种数据库管理系统更适合此类系统？
提前致谢。
I searched a bit for the differences between OODBMS and RDBMS. I pretty much know what they are. However, how I will decide which one is better for which applications. Can anyone kindly help me please?
What I meant for factory management is: there are production lines to manufacture bottled, frozen and other food stuff. The application manages from assigning staff onto the lines, to keep the production records in the system. Which dbms is better for such systems?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这是 Rick Grehan 撰写的一篇精彩文章，描述了 ODBMS 的有用之处：
http ://www.odbms.org/wp-content/uploads/2013/11/006.04-Grehan-When-to-Use-an-ODBMS-2005.pdf
Here is a nice article by Rick Grehan that describes cases where ODBMS are useful:
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 是为了解决不同类型的问题而发明的，而数据库应用程序碰巧不会遇到这种问题。
Disclaimer: this is an "old curmudgeon" answer, from a guy who wrote plenty of perfectly functional accounting, manufacturing and other code before OOP came into the mainstream.
With that being said...
Factory management is classic relational database stuff, it's what it was invented to do. The code for classic relational apps tends to follow very predictable patterns, lots of loops over retrieved rows from tables, or straight pass-through stuff: passing data up to the UI or down to the database. If your DB is well-designed, the biz logic you code will be details in those loops or pass-throughs, but those two patterns will dominate.
An OODMS on the other hand, from the point of view of this "old curmudgeon", attempts to recast the perfectly and efficiently functional RDBMS into something that will work with classes/objects, for no discernible gain over a system that has proven itself for decades to work extremely well. Classes have little or nothing to do with the classic code patterns that sit on top of relational databases. In fact, they tend to complicate things and can easily get in the way. I'm not saying don't use OOP code to deal with the database, just that OOP was invented for a different kind of problem, a problem that database apps don't happen to have.
选择 OODBMS 还是 RDBMS 的决定并不取决于工厂管理/自动化等特定应用程序。
它取决于许多标准，例如
1) 编程范式 - 如果您[程序员]选择以 OO 编程语言可视化/实现，那么 OODBMS 适合将对象直接存储到数据库中，但是最广泛的是关系型 DBMS 类型，因为它在商业上已经很成熟并且具有良好的数学背景。
2) 特定应用 - 对于工厂自动化/管理，响应能力和快速访问非常重要。 OODBMS 比 RDBMS 更快。如果您考虑进行 Web 开发，那么像 MySQL 这样的轻量级工具将很适合。
3) 趋势 - 现在出现了从传统/结构性编程到面向对象/组件编程的快速范式。因此，在这种趋势下，OODBMS最适合工厂管理等企业应用程序。
Decision to choose OODBMS or RDBMS does not depend upon particular application like factory management/automation.
It is depends on many criteria like
1) Programming Paradigm - If you [programmer] choose to visualize/implement in the OO programming language then the OODBMS is suitable to store the objects as directly into the database, but Most widely the type of DBMS Relational, because it is well established commercially and have a good mathematical background.
2) Application Specific - For an factory automation/management, responsiveness and fast access is important. The OODBMS are swifter than the RDBMS. If you considered for web-development then a light-weight tool like MySQL will fit a lot.
3) Trend - Now there is paradigm swift from Legacy/Structural to Object/Component Oriented programming. so therefore, in this trend the OODBMS is best suitable for the Enterprise Applications like factory management, etc.
这取决于应用层使用。如果它是一种更接近过程方式的简单方法[也可以有类]RDBMS 更合适。否则，如果您更倾向于严格的面向对象系统，则可以使用 OODBMS。
It depends on the application layer using. If it is a simple approach more towards procedural way [which can have classes too] RDBMS is more suitable. Otherwise if you are more towards a strict object oriented system OODBMS can be used.
我通常在它们需要集成到企业系统中时划定其有用性。如果您的项目不一定需要集成，ODBMS 通常更容易或技术更优越。如果您可以通过 Web 服务或“推/拉”集成到企业系统数据库中，那么您仍然可以使用 ODBMS，但可能会面临政治压力。 （较新的 ODBMS/RDBMS 复制，如 db4o 的 dRS 可能是一个不错的选择）但是，如果您需要与遗留或企业数据存储紧密集成，那么您通常会因为某种原因被迫使用 RDBMS。
也就是说，您的个人生产线可能会从 ODBMS 中受益匪浅，ODBMS 非常适合存储经常变化的复杂对象模型和模式，而协调器系统可以遵循我之前的思路。
我已经使用ODBMS很多年了，并且一直害怕这个需要我回到纯粹的关系数据管理的项目。尽管 ORM 工具的最新改进使关系型数据库的使用变得更加愉快，但 ORM+RDBMS 解决方案在一些关键领域仍然无法跟上 ODBMS 系统的步伐（请参阅 前面提到的 odbms.org 上的文章）。
I usually draw the line of usefulness at the point in which they need to be integrated into enterprise systems. If your project does not necessarily need to integrate, ODBMS is usually easier or technically superior. If you can integrate via web services or "push/pull" into an enterprise system DB, then you can still use an ODBMS, but there might be political pressure against it. (newer ODBMS/RDBMS replication like dRS for db4o may be a good fit) But if you need tight integration with legacy or enterprise datastores, then you're usually forced to use the RDBMS for one reason or another.
That said, your individual production lines might benefit greatly from an ODBMS which are great at storing oft-changing complex object models and schemas while the orchestrator system could follow my previous line of thinking.
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).