Re^4: How to implement set-style membership lists in my obejcts

I understand your second para, and yes, that is what I'm doing.

But would you mind explaining your first para? Why is the 1:1 actually 1 to many? Are you refering to the Object/Notice join, or to the Members table? I realise it is a many-to-many relationship, with a link table giving you many-to-one and one-to-many for notice and charity respectively. Is that what you're talking about?

I'm not familiar with the terminology, which is probably why I'm missing something here (eg 1::Oor1).

thanks moron

clint

Comment on Re^4: How to implement set-style membership lists in my obejcts

Replies are listed 'Best First'.
Re^5: How to implement set-style membership lists in my obejcts by Moron (Curate) on May 21, 2007 at 14:02 UTC
I was just trying to explain that whereas systems analysts were traditionally trained in a rich variety of relationship including 1:0/1 and 1:1, the modern technical implementation will be 1-many (or two 1-manys if necessary) to physically implement everything from the logical analysis -- see CJ Date, An Introduction to Database Systems, somewhere in the 1980s if I remember correctly, which seemed "modern" back then anyway :) update: to explain the 1:0or1, an example is employee -> employment details. On termination of contract, you might want to delete employment details but retain the employee header because the ex-employee still has pension rights being maintained in other tables. Later you might change your mind and just mark them deleted rather than physically delete them in which case it's a one-to-one but either way the physical implementation is still usually 1-many. __________________________________________________________________________________ ^M Free your mind!	[reply]

Replies are listed 'Best First'.

Re^5: How to implement set-style membership lists in my obejcts
by Moron (Curate) on May 21, 2007 at 14:02 UTC

update: to explain the 1:0or1, an example is employee -> employment details. On termination of contract, you might want to delete employment details but retain the employee header because the ex-employee still has pension rights being maintained in other tables. Later you might change your mind and just mark them deleted rather than physically delete them in which case it's a one-to-one but either way the physical implementation is still usually 1-many.

__________________________________________________________________________________

^M Free your mind!

[reply]