blocks|key|5349216|text|我们能回答不止一次吗？另一个原因是关系数据库在数学上有坚实的基础:从关系的定义，一直到范式，理论都是坚如磐石的。关系模型确实不能很好地映射到OO，但我认为该模型的好处和稳定性超过了映射问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5349217|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Can we answer more than once? Another reason is that relational DB's have a strong foundation in mathematics: from the definition of a relation, right through to the normal forms, the theory is rock solid. It is true that the relational model does not map well to OO, but IMHO the benefits and stability of that model outweigh the mapping problem.

blocks|key|3939388|text|主要原因是SQL。能够在应用程序之外的其他上下文中使用数据库中的数据是非常有用的，而且通常对于对象数据库，数据以一种不容易查询的格式存储。例如，使用关系数据库，数据可以成为数据仓库的一部分，或者只是由系统管理员等查询。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3939389|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The main reason is SQL. It is very useful to be able to use the data from a database in other contexts outside of the application, and often with object databases the data is stored in a format that can't easily be queried. With a relational database the data can become part of a data warehouse, for instance, or just queried by sys admins etc.

blocks|key|799566|text|我认为这是因为“对象数据库”正在解决一个(几乎)没有人真正拥有的问题。对于简单的对象图持久化，大多数OO环境中内置的序列化是“足够好的”。如果您想对数据的一个子集执行复杂的操作，那么关系数据库和SQL是完美的选择。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|799567|除了一些边缘应用程序(不能保存在内存中的巨大对象图，但关系不能很好地简化RDBMS使用)之外，真的不需要这些工具。|799568|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think it's because "object databases" are solving a problem that (almost)nobody really has. For simple persistence of object graphs, the serialization built into most OO environments is "good enough". If you want to do sophisticated operations on a subset of your data, then a relational database and SQL are a perfect fit.

Other than some fringe applications (enormous object graphs that can't be kept in memory, but for which the relationships don't simplify down well for RDBMS use), there really isn't any need for these tools.

blocks|key|3939542|text|仅仅因为OODB不是主流，我们仍然应该考虑它们所取得的成功。缓存和Zope都被广泛使用(相对来说)，但根据某些标准，它们被认为是成功的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3939543|也许，面向对象数据库没有大行其道的最大原因是混合对象-关系系统的成功，它们从面向对象数据库中夺取了大部分潜在的市场份额:+PostgreSQL和Informix。|3939544|我知道这不能直接回答问题，但我认为这是等式的一部分。不过，总的来说，我认为这种势头和支持关系数据库的根深蒂固的思维过程使人们很难切换。目前，DB专业人员几乎完全接受了关系理论方面的培训，这使得您的DB专业人员对避免OODB非常感兴趣，而学术界则为从业者讲授DB理论，几乎完全是关于关系理论的。|3939545|除非大型的企业DBA和主流教授和课程以及开发人员以外的人员准备管理OODB，否则我觉得无论它从开发方面多么好，都不太可能看到大众的吸引力。|3939546|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Just because OODB are not the mainstream we should still consider the successes that they have had. Cache and Zope are both widely used (relatively) but would be considered successful by some standards.

Perhaps the biggest reason that OODB have not taken hold dramatically is because of the success of the hybrid object-relational systems that take most of the potential marketshare from OODB: PostgreSQL and Informix.

I know that this does not directly answer the question but it is, I think, part of the equation. Overall, though, I think that momentum and the heavily ingrained thought processes supporting relation databases make it difficult for people to switch. Currently the DB profession is trained almost exclusively in relational theory making your DB professionals very interested in avoiding OODB and academia teaches DB theory for practitioners almost exclusively on relational.

Until large, corporate DBAs and mainstream professors and curriculum and turning out staff beyond developers prepared to managed OODB I feel that it is unlikely to see mass appeal no matter how good it is from the development side.

blocks|key|3093856|text|嗯，很奇怪，不是吗？领域驱动的设计是面向对象分析和设计的顶峰，有很多企业模式可以利用ORM系统来持久化我们的对象。在我看来，如果您的应用程序设计是面向对象的，并且本质上是以领域为中心的，那么OODB将会给您的应用程序带来极大的好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3093857|除了围绕成熟度和吸收的问题之外，从哲学的角度来看，OODB似乎是有益的或OO应用程序。无需维护初学者的映射层；)|3093858|但是，如果你不进行域驱动设计，使用对象作为数据对象，就像你存储的proc一样，那么你就不会真正得到它；)|3093859|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Well, it's strange isn't it? There is such a push towards domain driven design as the zenith of object orientated analysis and design, and there are enterprise patterns out there to leverage ORM systems to persist our objects. It just makes total sense to me that if your application DESIGN is object orientated and domain focussed at heart, that an OODB will greatly benefit your application. 

Aside from the issues around maturity and uptake, from a philosophical perspective an OODB would appear beneficial or an OO application. not having to maintain that mapping layer for starters;)

But look, if you aren't doing domain drive design and use objects as data objects and like your stored procs, then you're not really going to get it;)

blocks|key|3939641|text|RDBMs+(建立在强大的理论基础上，已经在市场上存在了很长时间，在许多情况下可以比OODB更忠实地建模数据，可以被更多的DBA而不是OODB使用)。这是以关系元组的形式存在的原因之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3939642|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

RDBMs are (built on a strong theoretical foundation, have been in the market for a much longer time, can model data more faithfully than OODBs in many cases, can be used by more DBAs than OODBs). That's one reason in the form of a relational tuple.

blocks|key|5349152|text|如果我可以扩展一下Phil的观点:+SQL的标准化。OODB已经尝试过OQL等查询语言，但它们似乎从未遵循过真正的标准。查询语言的质量也是可疑的，可以说是由于缺乏标准化。标准促进了竞争，从而产生了质量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5349153|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If I can amplify Phil's point: the standardization of SQL. OODB's have tried query languages such as OQL but they never seemed to follow a true standard. Also the quality of the query languages were suspect, arguably due to lack of standardization. Standards foster competition, which spawns quality.

blocks|key|3093890|text|一个原因是数据库是关于数据的，而对象是关于结构和算法的。一旦获取数据并将其嵌入到类中，就可以在静态结构中表征关系和操作。另一方面，数据库是关于将数据拆分成一组原子表的实例，这些实例可以重新组合成不同的结构(通常使用类)，而不会影响原子的完整性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3093891|数据库在某种程度上类似于hexahexaflexagons。|3093892|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One reason is that databases are about data, and objects are about structures and algorithms. Once you take the data and embed it in classes, you characterize the relationships and operations in a static structure. Databases, on the other hand, are about unstructuring the data into a bunch of instances of atomic tables that can be reassembled into different structures (usually with classes) without disturbing the integrity of the atoms.

Databases are somewhat analogous to hexahexaflexagons.

blocks|key|803665|text|还有o/r-mappers。通过它们，与真正的OO-DB的区别变得小得多，而前面提到的好处仍然有效。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|803666|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

That, and o/r-mappers. Through them, the difference to true OO-DBs becomes way smaller, while the aforementioned benefits stay valid.

blocks|key|803884|text|昂贵的技术决策不是由具有技术知识的人做出的。使用关系数据库的公司雇佣了很多觉得受到OODB威胁的人，因此会避免学习OODB。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|803885|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Expensive technology decisions are not made by people with technical knowledge. Companies using relational databases employ lots of people who feel threatened by OODBs and therefore will avoid learning about them.

blocks|key|3939688|text|我认为有两个哲学上的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3939689|首先，人们传统上倾向于将持久性与真正的功能分开。一旦您剥离了对象的“生命”，并将其主要用于持久化，它就变成了一条记录，然后有一种将其视为“无生命”数据对象的趋势。|3939690|接下来，当人们想到一大堆非常相似的东西时，他们开始把它们看作是表而不是对象。|3939691|我认为，随着O/R的出现，这种区别开始消失。例如，我使用hibernate将非常复杂的类层次结构转储到MySQL数据库中。然而，我不会为我的项目编写性能关键的东西，所以我确信它不会高效地完成。|3939692|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think that there are two philosophical reasons.

First, people traditionally tend to separate persistence from real functionality. Once you strip away an object's "life" away from it and keep it primarily for persistence, it becomes a record, and then there is a tendency to treat it as a "lifeless" data object. 

Following on that, when people think of a large collection of very similar things, they start thinking of them as tables rather than objects. 

I think with O/R the distinction is starting to disappear. For example, I use hibernate to dump really complex class hierarchies into a MySQL database. However, I don't write performance-critical stuff for my project so I'm sure it's not done efficiently.

blocks|key|3940007|text|OODB采用缓慢的原因主要基于使关系SQL数据库更流行和/或更合适的几个关键因素。虽然纯面向对象的数据库现在克服了关系模型的许多缺点，但仍然缺少一些关键部分。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3940008|首先，它们往往缺乏对中央数据库管理的支持，尽管这在各种产品中正在迅速得到纠正。|3940009|第二个原因是很少有系统实现标准查询语言，而是依赖编程语言或专门的查询语言来检索和操作存储中的数据。对于许多人来说，如果他们必须在程序员习惯于基于NoSQL的解决方案的完全不同的心态之上学习一种新的查询语言，这将是一个停滞不前的问题。最重要的是，大多数基于SQL的/关系型数据库现在都支持面向对象的设计，而且我们还有像ORM这样的包装器，许多人用它来“绕过”关系型数据库在所选编程语言中不可用的问题。|3940010|但这些问题大多存在于企业环境中。作为小型设备、网站存储和航空航天等领域的嵌入式数据库，它们已经变得非常流行，在许多情况下完全取代了对常规关系数据库的需求。|3940011|谁知道未来会怎样呢？|3940012|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

The reason for the slow adoption of OODB's are based largely on a few key factors that make the relational SQL databases more popular and/or more appropriate.
While pure object-oriented databases are now in a state where they overcome much of the drawbacks of the relational model, there are some key pieces missing. 

For one they tend to lack support for central database management, though this is rapidly being rectified in various products.

A second reason is that very few systems implement a standard query language and instead relies on the programming language or specialized query languages to retrieve and manipulate the data in store. This is a show stopper for many if they have to learn a new query language on top of the totally different mindset of a programmer used to NoSQL based solutions.
On top of that, most SQL based / Relational databases now have some support for Object Oriented Design, plus we have wrappers like ORM that many use to "bypass" the problems of relational databases not being readily available in the programming language of choice.

But these problems exist mostly in corporate environments. 
As embedded databases in small devices, as web site storage and in fields like aerospace they have become very popular and in many cases totally replaced the need for regular relational databases.

Who knows what the future holds?

blocks|key|804017|text|大多数语言提供的序列化允许您将对象属性转换，从而轻松地将它们存储到RDBMS中，并且类似地检索对象也不是什么大问题。广泛而坚实的基础仍然缺乏，这阻碍了OODBMS的使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|804018|我目前正在考虑将此作为我的硕士论文项目，为OODBMS提供一个通用的框架，该框架支持当今RDBMS中常用的几乎所有组件，从而提供一个非线性的结构化DBMS。在学习的过程中，我遇到了一个名为db4o的项目，它是一种只在Java和.net上使用面向对象数据库管理系统的方法(实现)，因此这可能是对所有类型的平台和语言缺乏通用性的另一个原因。|804019|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Serialization provided by the most of Language lets you flaten the Object attributes and thus storing easily them into the RDBMS and similarly retrieving objects is not a big issue. The wide and solid foundation still lacks which hinders the use of OODBMS to be implemented.

I currently thinking of doing this as my Master Thesis project to provide a general framework for OODBMS that supports almost all the components which is commonly used in now a day RDBMS thus providing a non-linear structured DBMS. While studying I came across a project called db4o which is an approach (implemented) of using OODBMS for Java and .net only, so this could be another reason of lack of generality for all types of platforms and languages.

blocks|key|5349644|text|我认为这是因为像甲骨文这样的大公司在面向对象的运动获得momentum...may的同时一直在投资关系数据库，如果甲骨文/微软投资在大型way...which上，他们将成为主流似乎不太可能，因为他们没有强有力的理由去做so...it将简化许多programmers...but的生活，“让程序员的生活更简单”对他们来说不是一个很好的商业目标。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5349645|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think that's because big guys like Oracle had been investing in relational databases while object oriented movement was getting momentum...may be they will become mainstream if Oracle / Microsoft invest in it in a big way...which seems unlikely because they don't have a strong reason to do so...it will simplify lives of many programmers...but "making programmers lives simpler" is not a very good business goal for them!

That's the question. Give only one reason you think why have OODB failed or why many systems nowadays still use relational databases.

Why have object oriented databases not been successful (yet)?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

这就是问题所在。只给出一个你认为为什么OODB失败的原因，或者为什么现在许多系统仍然使用关系数据库。

问为什么面向对象的数据库还没有成功呢？
EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么面向对象的数据库还没有成功呢？EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么面向对象的数据库还没有成功呢？
EN