Chris Nighswonger wrote:
Hi all, I'm beginning preliminary design work on a membership module for LedgerSMB. One of the basic features of this module will be attendance tracking. I would like to hear suggestions on how the relationship between members and events should be handled. Currently my considerations include two tables with possibly a third. There is a memberinfo table which includes mem_id as the pkey, and there is an eventinfo table which includes event_id as the pkey.
This seems like you would want to play off the upcoming CRM features where memberinfo would point to the entity_details table and you would have a entity_type of member or something like that to build out the relationship.
J It appears that
this is a many-to-many relationship. What I am questioning is the third table (?). One which would gain a new column for either each event or each attendee, and a new row for the one not becoming a column. However, this appears to me to have the potential to become very bulky. Maybe this table (as well as eventinfo) could be archived off on some periodic basis (yearly) to keep it from growing too large. Any thoughts? Is this an entirely incorrect approach? Thanks, Chris ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel