Are the non-members information important after the meeting? Are there non-members, who participates repeatedly? Must non-members provide information on themselves every time, or can they use their previous non-member information?
What are the current use of the members? Does the non-members conflict with that usage? My suggestion is (until the above is clarified): one meeting -> has many -> attendees -> which may be -> a member or a non-member In CakePHP terms: meetings -> attendees <- members meetings -> attendees <- non-members Enjoy, John On Sep 9, 6:17 am, brian <bally.z...@gmail.com> wrote: > On Tue, Sep 8, 2009 at 3:56 PM, mike karthauser<mi...@brightstorm.co.uk> > wrote: > > > brian wrote: > >> I'm building a site for an industry organisation and have a tricky (I > >> think) architecture problem. There's a table for members, with first & > >> last name, email, password, etc. The org has meetings--usually > >> annually--for which anyone can attend. However, there is a charge for > >> attendance, and all attendees must be recorded. Because there may be > >> both members and non-members, I thought that the simplest solution > >> would be to create a non_members table, which has many of the same > >> columns as members. I'm not really keen on doing any sub-classing > >> here. > > >> Anyway, so, if I have members, non_members, and meetings tables, I > >> figure that I can then create a meetings_attendees table. Basically, > >> the attendee can be either a member or a non_member. Should I go with > >> a schema like this? > > >> meeting_id > >> member_id > >> non_member_id > > >> This seems like a kludge, at best (if not broken). Can anyone suggest > >> a better approach? > > > if the main difference between the two groups is whether they are member > > or not, why not settle on a 'users' table with a is_member boolean. You > > can then have a model for members and nonmembers separately if you like > > (by specifying the condition users.is_member =>1) and then have the > > option of trading up a member from a non member by switching a field value. > > > keeps it simpler. i usually start with users and groups which then gives > > you the option of specifying different member types as well including an > > addition switch for super_user or admin which can prove handy. > > Yes, I think I'll go with yours and Miles's idea. I'd thought about it > earlier but dismissed it because I didn't want to have certain fields > required for members but not the others. But I think it'll work out > ok. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
