Hi, No, I didn't do it with inheritance on purpose as I'll need to switch classes in time. I mean, a person might be a user later in time. Then I'll need to switch classes (which wouldn't be that easy as all the related complex objects of the person should somehow be copied to a User object... And that class switch might also happen backwards in time.) First thing I thought of was to use inheritance but this would bring many complexities.
Creating a unique index on the many side would prevent me from adding erroneous records and eventually reaching a crippled one-to-one (as it will be sth more like "one-to-collection of one") but I'll have to implement many things manually. If I have to do lots of things manually, I guess I'll go with plain properties in both classes which mutually update the corresponding property in the other class. After I posted the message I've bumped into a long discussion in the archive about one-to-one implementations, and I guess it will be the best, if I have to implement it manually. Anyway, thanks for the ideas and best regards.... Teoman "Gershon Simcha" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Theoman > > I think you confuse bettween relationship & inheritance. > Relationship is more like joint tablebles. > The case you describe is classical for inheritance User from Person so you > can apply by a person object to use and vice versa. > One to One relationship is basically an extention of a class (in which case > why not to do one class). > > Hope i did clarify things - Simcha > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.744 / Virus Database: 496 - Release Date: 24/08/04 > >
