From: Kevin Brown <blargity@...>
Date: 2005-09-13T16:16:32+09:00
Subject: Re: KirbyBase

On Monday 12 September 2005 22:10, Ezra Zygmuntowicz wrote:
> On Sep 12, 2005, at 7: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
> >>> like in object terms? So I decide it must correspond to an array
> >>> inside my Foobar object. And it doesn't sound like something I would
> >>> ever really use or see a need for. But to accommodate the case that
> >>> I might use 3% of the time, the syntax for the case I use 97% of
> >>> the time has to become five times nore complex. (Granted, once I
> >>> get into it more deeply, I might be glad to have "one-to-many" and
> >>> use it in ways I don't foresee now.)
> >>
> >> class moo
> >>   def initialize
> >>     @1 = Time.now
> >>     @2 = Time.now
> >>   end
> >> end
> >> moo.new
> >> Moo now contains many Time objects.  Throw it at KirbyBase, and
> >> you want a one to many (which just means that one moo contains
> >> many time objects).  There's no reason to have multiple Time
> >> tables (one for each instance) when they're the same fields, no?
> >> You're right, this would usually fall out of an array, and it's
> >> when you want one to many relationships implemented.  This happens
> >> a LOT in the real world (at least in my programming style).  Hope
> >> this helps clear up the 3% to 97% analogy. :-)
> >
> > I had to spend an hour or so thinking about this (read: napping)
> > but now I
> > think this reveals a flaw in my thinking.
> >
> > In this actual case, a DateTime would be stored as a "simple" type.
> > And I
> > don't think @1 and @2 are valid names. ;)  But that is all beside
> > the point.
> >
> > Suppose someone had two bosses (heaven forbid), boss1 and boss2.
> > Then I suppose
> > there would be a one-to-many relationship as you say.
> >
> > 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?

In relational database design you DO store a seperate key for each. :-)  The 
one to many relationship (again, in traditional DB design which doesn't have 
much bearing on this anyway) simply means that one item can 'contain' 
multiple items.

Say for instance that we had an account that could have notes associated with 
it.  These could be stored in an array or seperate variables (as it really 
doesn't matter, it's just how you group the data.)  In traditional db design 
you'd have one account entry in an account table with id say 29 for example.  
You then have two notes entries, each with 29 in their foreign key field to 
person.  Then, if you go to get notes for account 29 you grab all notes where 
their foreign key to person == 29.  This is a one to many relationship 
because one account 'contains' multiple notes.

So the minute logical difference we're arguing here is whether you should have 
two links, Person => Note for the first one, and Person => Note for the 
second, or one link that says Person => [Note, Note].  So, in my opinion, you 
do have a one to many, not two one to one relationships, however, in code, I 
suppose you could implement separate links and then count all the links (read 
slow) to fake one to many. :-)

Hope I'm clearer this time.