On 28.01.2011, at 11:56, Stephan Eggermont wrote:
On 24 jan 2011, at 23:47, Norbert Hartl wrote:
It is hard to tell. Usually you can assume that
an OODB is more partitioned (data wise) than a relational database. This leads to more
seeks on a hard drive.
Not when using an OO model and following the navigation. Objects that are created
together are close together. A simple example: An order has orderlines. In an OODB you
would expect the orderlines to be on the same (or next) page on disk. With a RDBMS, you
need to access two tables, and have two seeks. A full table scan over orders though is of
course slower with an OODB, as more pages need to be loaded.
I don't know if we are talking about the same. You are saying "two
seeks". You mean database "seeks"? I meant hard disk seeks which are
probably a few hundreds when doing a query like you stated above. I think your example is
a bit misleading because it is IMHO oversimplified and combines with assumptions I cannot
share.
Can you give evidence for what you are stating? I think you cannot assume that objects
created together (time wise) are written together. That seems only be valid if you name a
certain database technology name. That would be the case if you just add objects and claim
new pages if your current one is full. Furthermore I think there is a big distinction
between objects that are created together and objects that are used together. The latter
one being much more important.
In the RDBMSses I know the index and the data is stored in a format that needs less
overhead if you query a lot of objects of the same kind. So the load of an RDBMs can be
anticipated by a query whereas that it is seldom the case for an OODB. It is exactly like
you said. You follow the navigation but then you have to be sure that the data is
constructed that way. Saying it would be rather easy to know you have to fetch 3 rows from
one page in an RDBMS environment. In an OODB you only know it at the end. Without caching
you could read the same page three times. And here gemstone does a create job having a
shared page cache that makes this a non-issue.
Norbert