i'd choose your first suggestion.
Using the calendar table (you can use the date field as Primary Key) and
the other tables (birthdays,testpapers,....) where you could use the date field as Foreign Key.
With simple 1-N relationships you can solve the prob.
hope it helps.
Rui Cunha
Arnout Boks writes:
Hi,
I'm currently working on a php-based community website for my school class.
Part of that website is a calendar function that includes the dates of all
testpapers, birthdays, school parties and so on...
Of course, a testpaper has got other properties than a birthday, so they
should go into different tables with different fields.
They have to be mixed when showing the calendar overview, but the detail
pages should be different for each type of calendar entry. After some
thinking, I came up with two different solutions:
I: Make one table 'calendar', which contains all the common fields(like
date, time etc.). Make tables 'birthdays', 'testpapers'... and link each
record in them to a record in the calendar with a 'calendar_id'.
II: Create only tables 'birthdays', 'testpapers'.... and combine them
with a UNION statement.
Could someone give his/her opinion about what he/she thinks to be the best
solution. (I use MySQL, if you need to know.)
Thanks in advance,
Arnout
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
