New answers tagged

3

I wouldn't have the ContactInformation linked 1-to-1 to Person anyway; storing several addresses like that in ContactInformation violates normal form. Instead I'd have ContactInformation with its own PK, an FK for PersonID back to the Person table, and store as many Contacts as necessary for each Person. CREATE TABLE ContactInformation ( ContactID int ...


-1

Your already have it setup just create a new record in the "ContactInformation" table with the same PersonID and then the person has two addresses


0

Possible solution to account for the helpful info in the above two answers: `form_control` form_id primary_event_id (foreign key in `event_dates`) default_event_id (usually same as primary date) primary_event_host_id (foreign key `event_speakers`) default_start_date_time (actual or arbitrary start point) default_end_date_time ...


0

Yes, it's correct, although, as noticed by yourself , it's pretty crude. This has been asked months ago. Why didn't anyone answer it yet? Are you still working on this project? I wonder if you really have the right skills to complete this... If it's indeed interesting, I could help you with the database architecture. One word of advice: MySQL does not ...


4

I think that at the end, event_dates will need to be partitioned. That will allow you to archive old events. form_control may need this also, and probably primary_event_date_id could be a candidate. I think, however, that the key from the ongoing and events, should be located at the same way in the form_control. For doing that, you will need to convert the ...


0

The way you've outlined it is how I would do this in a data warehouse. I've created relationship tables (mapping tables) to tie different dimensions together, because there are potentially many to many relationships between them. And because my tables have thousands and millions of records each, creating a denormalized table would be incredibly cumbersome ...


1

This looks like a school project correct? I think the confusion is coming in because your example is very simple (perfectly appropriate for a class/training environment). The design you have is considered best practice. The reason it might seem simpler to go with the denormalized design is because you have so little data/so few columns. If you add a ...


3

To focus on ongoing and future dates... A table with suitable columns for simple cases of repeated actions. One row per repeating event. No specific dates except start and end. A table for exceptions (extra dates, skipped dates, etc). This has a column with a specific date. This table could also handle simple, one-time, events. Application code that ...



Top 50 recent answers are included