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