The other approach I thought would be to model it similarly as to howDear Daniel,
I would do it in a relational database. Basically, I would create
separate collections of objects representing the tables I would have
in the relational database. Then, within each object, e.g. a customer
object, I would create a reference to a collection that holds a
subset of invoices, for example. This would allow me to simply query
the invoices collection of a customer and that's it. At the same
time, I would be able to query the entire invoices collection.
I think this approach is much better than creating a very large object.
Personally, I have an opinion a lot of people disagree with --- I use the "prevalence" model,
which is basically that I keep all of the objects in memory, and when I change something I
write back to the data store. This pretty much makes your reporting efficiency issues
go away, because you can compute any report really, really fast.
I have checked in, in the "contrib" directory, a packaged called DCM, for Data Collection Management,
that does the in-memory management --- the responsibility of the user is to call "register-object" whenever
an object needs to be back. DCM also supports the "reference" problem that you mention --- that is,
instead of putting a whole object into a slot, you put the key there and look it up in a separate object.
In this model, each class of object you would objectify (which is very similar to the "tables" in
relational model or "entities" in the entity-relational model.) Each should class gets a "director", and
you operate against the director when you do something. One of the advantages of this approach is
that you can choose the "strategy" for each director --- so you can choose to cache the objects in
memory, or to directly use the database store, or even to use a generational system.
I think the tests of DCM could be considered a little bit of pseudocode for what you want.
In considering whether or not things should be kept in memory, one should do the math: the
maximum number of objects * their size vs. the free memory. Memories are big and getting bigger.
Let me know if this addresses you ideas or if you have any other questions; Ian and I had
previously agreed that the lack of a big example application is one of the biggest weaknesses in
Elephant right now.
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
