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

Technically your 1:1 are really 1 to many because 1:(0or1) is implemented in practice as a 1 to many inthat order. The set/notice is in theory a many-to-many which is more normally implemented as member -< member-notice >- notice with member-notice as the link table, so that the "set" is really a view on member-notice for a given notice.

What I'd be doing about sets is making a container object "set" that requires an instance variable to have a particular notice filled in so it can go retrieve all member-notice pairs for that notice, thereby populating the container class.

__________________________________________________________________________________

^M Free your mind!

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

Replies are listed 'Best First'.
Re^4: How to implement set-style membership lists in my obejcts by clinton (Priest) on May 16, 2007 at 15:44 UTC
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	[reply]
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]