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?


Hal