面向对象的数据库 - 为什么大多数公司不使用它们 [英] Object Oriented Database - why most of the companies do not use them

查看:133
本文介绍了面向对象的数据库 - 为什么大多数公司不使用它们的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚完成了编程(刚刚完成大学)。



过去4年来,我一直在面对面向对象开发和这种方法的众多优势。



我的问题是



在开发应用程序中使用纯面向对象的数据库不容易吗? / p>

为什么面向对象的数据库不像关系数据库一样多?



从我的角度来看,使用OO数据库,后者将避免在表上映射复杂对象所需的众多构造。

解决方案

面向对象数据库公司过去( www.objectstore.com ) - 目前 - 我认为我有一个公平的见解什么使他们伟大,什么使他们不那么伟大。



很棒:



没有对象关系不匹配。如果要将内存中的对象x存储到永久存储器中,ObjectStore可以使用近乎实时的保证。我们的产品已经被许多公司使用,以满足与关系数据库或ORM引擎难度相对的残酷时间要求。



没有对象关系不匹配 - 您在对象中开发,您在对象中考虑,存储在对象中。



不太棒:



ORM:对象关系管理员有漂亮很多对象数据库无关



模式演变:更改一个类来添加一个字段,现在你必须变形一个ENTIRE数据库。 ObjectStore多年来已经变得更加聪明了,但是对于许多OODBMS来说,这仍然是一个难题。



不好:



工具支持 - 大多数地方开始。每个人今天都可以使用水晶报表或访问或Excel,并且可以产生大量报告。使用OODBMS,您必须通过程序员构建此逻辑,并且我们都知道,如果您需要预算报告来考虑在设计时您没有想到的一些xyz参数,那么可能会发生多快的事情。



工具是OODBMS在市场上失败的原因。不是技术优势或性能或语言支持(ObjectStore支持C ++ / Java / .Net,并支持COM支持任何IDispatch语言,如VB,Perl等)。



所以我在这里说了一些贬低的东西,特别是关于我真正喜欢的产品。但是ObjectStore在非常具体的任务中是非常棒的,但是构建webapp的选择很差。虽然有一点,它正在推动库存管理后端 Amazon.com


I am pretty new to programming(just finished University).

I have been thought in the last 4 years about Object Oriented development and the numerous advantages of this approach.

My question is

Isn't it easier to use a pure Object Oriented database in development applications?

Why Object Oriented database are not as much diffuse as relational?

From my point of view makes sense to use OO database, the latter will avoid the numerous construction necessary for the mapping of complex objects on the tables.

解决方案

Having worked for an Object Oriented Database company in the past (www.objectstore.com) - and currently - I think I have a fair insight on what makes them great, and what makes them no-so-great.

Great:

No object-relational mismatch. If you want to store object x in memory to a persistent store, ObjectStore can do it with near-realtime guarantees. Our product has been used by many companies to meet brutal time requirements that would be tough with relation databases or ORM engines.

No object-relational mismatch - you develop in objects, you think in objects, you store in objects.

No-so-great:

ORM: Object relational managers have pretty much made Object databases irrelevant

Schema evolution: Change a class to add a field, and now you have to morph an ENTIRE database. ObjectStore has gotten smarter about this over the years, but it's still a pain point for many OODBMS.

Bad:

Tool support - this is what made OODBMS a non-starter for most places. Everyone today can take Crystal Reports or Access or Excel and churn out bucketloads of reports. With an OODBMS, you would have to build this logic through a programmer, and we all know how fast that's likely to happen when you need your budget report to take into account some xyz parameter that you didn't think of at design time.

Tools are why OODBMS failed in the marketplace. Not technical superiority or performance or language support (ObjectStore supports C++/Java/.Net and had support for COM to support any IDispatch languages like VB, Perl, etc.).

So I've said some disparaging things here, particularly about a product I really like. But ObjectStore is awesome at very specific tasks, but a poor choice for building a webapp. Though at one point, it was driving the inventory management backend for Amazon.com.

这篇关于面向对象的数据库 - 为什么大多数公司不使用它们的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆