> > Another issue that I can see is that of performance in for instance >> JDBM... I would assume that making many key lookups are relatively >> expensive, and we would need to look at "Lookup/Size speed ratio", >> i.e. how many bytes larger blob in the single lookup is required cost >> wise for each new key-lookup? >> > > I think there are two issues: one is the expense per lookup, and one is > that with more key->value mappings the database is going to be bigger, so > will consume more disk space. The indices will also be bigger and thus > slower. > > What would be interesting is to have the store work on two levels: one is > the identity lookup, and then the next level would be property(/association) > lookup. If one index can have only identity lookup and another has the > per-property lookup, it should be much faster. >
Isn't there also a problem with the many association? I mean wouldn't you *have* to support some kind of pagination on that? Maybe that is a modeling issue, but what if the domain suggest that you have a many association containing 10000 or more entries. Then when reading the entity, it will load all of the them in a list. But pagination would pollute the api and will probably be tricky to implement. Maybe it would be possible to do some automatic pagination when persisting, i.e. storing 100 items and then pointing to the next page. This does not solve the size issues, as you would get many more entities in the data store then... Just a thought. Regards, Mads
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
