[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestions for Table Design for Attendance tracking

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.


 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?


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.
Ledger-smb-devel mailing list