[Seaside] GOODS design question

[Avi Bryant]

On Jun 16, 2004, at 2:05 PM, Brian Murphy-Dye wrote:

> I'd like to try using GOODS, but don't know how to design an object 
> database. For example, in a relational database used for school course 
> scheduling, there is basically a one-to-one mapping between the 
> classes implemented in Smalltalk and the tables in the relationship 
> database (with the addition of tables for the many-to-many 
> relationships). But if you do something like 'db root at: 'Micky 
> Mouse' put: aStudent' in GOODS, all of Micky's classes will be stored 
> as well (assuming there is a 'classes' instance variable in the 
> Student class), and then all of the students in those classes. Is this 
> acceptable or should I design my classes so they don't contain other 
> objects?

That's totally acceptable.  Indeed, that's the whole point: that you 
can use normal references between objects, and the usual collection 
classes, and so on, without having to worry about joins.  One tradeoff 
is that you have to managed indexing yourself - a more realistic 
version of your example might be

(db root at: 'studentsByName') at: 'Mickey Mouse' put: aStudent

where you might also maintain studentsByStudentNumber, coursesByID, and 
so on.  You'll generally need to use one of those indices to find the 
main object you're interested in, and then follow references to other 
objects from there.

I should also point out the BTree package on SqueakMap - if you were 
going to have, for example, 5000 students indexed by name, you would be 
much better to use a BTree for the index than a normal, hashed 
Dictionary.  It would be nice to see some other data structures (Trie 
comes to mind) if anyone has time... the performance characteristics of 
an OODB are (perhaps obviously) much closer to disk than to RAM, so all 
those data structures you learned about in school but rarely use are 
suddenly important again.  ;)

Avi