> Performance for "query" style interactions is generally worse for object
> databases
Agreed.
> though looking up related data to an object is generally better, but not by
> much
Really? I thought it was faster by quite a bit. But I think you could be right. With indices in
RDBMSes, looking up related objects won't be slow at all.
The show-stopper with object databases could be the querying. It's very very fast to look up one
object, plus all of that object's children (related entities). However, it's a real pain to scan
through several objects and filter them through a series of conditions. Maybe, think of RDBMS data
structure like the quick and fine-grained RISC instructions, as opposed to the CISC ones.
Or maybe it's just that object databases haven't seen much optimizations yet.
RDBMSes are wickedly optimized by now, IMO.
Jonathon
David E Jones wrote:
>
> Performance for "query" style interactions is generally worse for object
> databases (though looking up related data to an object is generally
> better, but not by much), which is one of the reasons they don't work
> well for many business applications and have not really caught on as
> much even thought they have been around for like 30 years or something.
>
> -David
>
>
> Adrian Crum wrote:
>> I agree with David. I can't imagine any reason why one would trade in
>> the relational model for an OO one. If OFBiz's performance is an
>> issue, then maybe you should invest in a better database or faster
>> hardware.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>>
>>> Actually no, the Entity Engine never does object-relational mapping.
>>> There is never a mapping to an object form for data structures in
>>> OFBiz. The is the whole point of how the entity engine, service
>>> engine, form widget and other related elements are designed.
>>>
>>> OR mapping is a waste of time, so we use relational data structures
>>> top to bottom and have tools to make that easier.
>>>
>>> -David
>>>
>>>
>>> David Shere wrote:
>>>
>>>> The ad I'm looking at says:
>>>>
>>>> "To store Java objects, relational and object-relational databases
>>>> must translate them into another format. This object-relational
>>>> mapping (ORM) is a drag on performance and boosts storage demands.
>>>>
>>>> "McObject's Perst, as an all-Java, object-oriented database, stores
>>>> Java objects as Java objects, for greater efficiency and
>>>> performance, and a smaller footprint."
>>>>
>>>>
http://www.mcobject.com/perst>>>>
>>>> Is the relational data model you're talking about not the same as
>>>> the object-relational database this ad is talking about?
>>>>
>>>> David E Jones wrote:
>>>>
>>>>>
>>>>> If it persists Java objects then it is an object database and not a
>>>>> relational one. OFBiz is built on a relational data model and
>>>>> relational database. These two are VERY different so no, you
>>>>> couldn't use it with OFBiz unless it has a relational layer (with
>>>>> JDBC driver) built on the object database.
>>>>>
>>>>> For anyone curious this is an interesting little bit of computer
>>>>> science to read about, but I don't know of any good, accessible
>>>>> resources on the net (just old textbooks for me...).
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> Adrian Crum wrote:
>>>>>
>>>>>> OFBiz attempts to be database agnostic. Database vendor specific
>>>>>> features are avoided.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David Shere wrote:
>>>>>>
>>>>>>> I've read about this Perst database that stores Java objects as
>>>>>>> Java objects. Has there been any talk about Ofbiz using this?
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Locked
smime.p7s (3K) 