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. mikek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
