A question of concept/logic

  • Thread starter Thread starter The Dude
  • Start date Start date
T

The Dude

Hello folks,

I would really appreciate your help on the programming logic of the
following example:

Let's say you have an invitees table with Invitees_ID and Invitees_Names
Assuming that you have another table this time with Events_ID and _Name.

Now I would like to be able to select invitees, some of them, and invite
them to q selected event.
Which logic should I use:
- Make a third table with gathered Invitees_ID and Events_ID?
- Make a table for each events' year so that it can last in the future?

Any correction/info will be greatly appreciated :)

Have a nice day
 
Use the third table. What you have is a classic many to many relation ship.
That is, one Invitee could attend multiple events and on event can have
multiple invitees. So your third table is known as a junction table.
Juntion tables are used to resolve many to many relationships.

Do Not separete years in different tables! That is a serious design flaw.
Just add a date field to the third table to identify the date of the event.
Then you can easily use a query to filter by a specific year.
 
Thanks a lot Dave!
Good information here...


Klatuu said:
Use the third table. What you have is a classic many to many relation ship.
That is, one Invitee could attend multiple events and on event can have
multiple invitees. So your third table is known as a junction table.
Juntion tables are used to resolve many to many relationships.

Do Not separete years in different tables! That is a serious design flaw.
Just add a date field to the third table to identify the date of the event.
Then you can easily use a query to filter by a specific year.
 
Dave,

I have a question though in the concept of that junction table:

Let's say the columns are invitee_ID and event_ID
If one invitee attends three different events, should it make three lines,
two columns - or one line, four columns?
I know how to make the first one... simple... but is it considered as
redundant information (that is the second method does not show twice the
invitee_ID).

I hope I am clear enough... ;)
 
Definitely three rows. It would be a mistake to use multiple fields and have
a single row: that's known as a repeating group, and is not a good thing.
 
Back
Top