On Monday 12 September 2005 10:53 pm, Hal Fulton wrote:
> Kevin Brown wrote:
> > On Monday 12 September 2005 17:06, rubyhacker / gmail.com wrote:
> >>Randy Kramer wrote:
> >>7. And I think: What would a one-to-many databasse relationship look

> And yet, no. I retract that. There would be *two* one-to-one relationships.
> You could store a separate key for each. You only have a one-to-many when
> you use the same field to look up a variety of child records, correct?
> Resulting in, essentially, an array of rows?

A few things:
   * (aside) the attribution above is a little misleading (not if you read it 
carefully, though)--I did not write what is in the item 7
   * my background is more in relational database systems than, for example, 
in objects in any way shape or form--my earlier answers were purely from the 
viewpoint of a "traditional" relational database (hence I feel like I'm in 
over my head and should try to bow out gracefully but quickly ;-)  (And, I'm 
not an expert in relational databases, just struggled with them a few times, 
in the "good old days". ;-)

   * re the last paragraph above, yes, (in a vacuum) you could look at the two 
situations above as either a one-to-many relation or two one-to-one 
relations, but unless there is some mitigating circumstance (which I won't 
try to imagine atm), in a relational database "world" (i.e., by relational 
database practitioners, it is a one-to-many).  I won't try very hard to 
explain why, but I'll throw out words like normalization (generally, getting 
the database in a form that minimizes the duplication of information) and ask 
one (hopefully leading question):  

Consider your example of "someone" having two bosses.  What you suggest (to 
treat that as two one-to-one relations) is to have two boss fields in the 
"someone" record--one pointing to boss1, one pointing to boss2.  So, what do 
you do when you encounter someone else with 3 bosses?  In your scenario (and 
a relational data base world, you'd have to modify the "someone" table to add 
an additional column for the third boss.  In a normalized relational 
database, you'd just add another boss record to the boss table pointed to by 
the same key that points to that someone's first and second boss.

   * Now, not knowing anything (?) about object databases (is that what 
KirbyBase is trying to be) (and not all that much about objects) my 
impression is that object databases are not nearly as structured as a 
relational database, in fact as someone else mentioned (iirc), they are 
almost more of a persistence mechanism so that when you restart an 
application after a shutdown, you can recover data that might have been 
captured in prior "runnings" of that program.  My impression is that there is 
(can be) a pretty ragged mixture of objects of all shapes and sizes.

(The object database / persistence mechanism that I have the most knowledge / 
experience with is the one in Instiki (is that Madeleine) and that only based 
on a short experience with installing and using a local Instiki.)

I guess I'd think two things:  I'd like anything that billed itself as an 
object database to be able to handle any object (no matter how convoluted, 
more below) with something like one save command (and later, one load 
command).

By convoluted, I'm trying to remember (without looking back) how you defined 
the objects you used as examples.  Seems there was one "main" object that 
included some sub-objects.  (ATM, I don't have any feel for the right 
vocabulary (its not "inheritance" iiuc) to describe that situation, nor do I 
know whether objects can have sub-objects (I know objects can have attributes 
and methods, but I never thought in terms of sub-objects), but, if that is 
possible, I would hope for an object data base that could handle such an 
object in "all its glory" (ie., with its subobjects) as simply as possible 
(one command to save, one command to load).

On the other hand, I can imagine simplified object databases with limited 
scope for various reasons (reduced complexity, whatever), that would not 
undertake to handle such complex objects but instead require that the various 
subobjects be stored separately.

So, I can see that going either way depending on the aims of KirbyBase.  (And, 
of couse, nobody needs my blessing/permission/agreement to implement whatever 
they want. ;-)

Hope something here helps, or I've not made to much noise.

regards,
Randy Kramer

I can