Question

If I have a schema similar to this:

TABLE 1  
id  
column  
other_column  
etc

TABLE 2  
id  
table1_id  
some_other_table_id

Is it a good idea to add a third table like this:

TABLE 3  
id  
table2_id  
row_from_another_table_id

EDIT:
To make things clearer, consider a schema like this:

EVENTS  
id  
name  
other_stuff 

RANGES  
id  
time_from  
time_to  
max_people  
etc

EVENTS_PLACES  
id  
event_id  
place_id

What I want to do is to define a time range for an event. But a specific event in a specific place(EVENTS_PLACES) can ‘overwrite’ this ranges. Also an event can have multiple ranges.

I hope this makes the question a little bit more clear now.

Answer 1

Its always been my impression that a many to many relationship is a violation Boyce-Codd Normal Form and therefore a violation of a good relational database schema.

Therefore, relating data to a link table is, infact, necessary to achieve BCNF and therefore good. If avoiding data update anomolies is good.

---

On to the specific schema example you presented. I think you want these logical tables (or entities),

-----------------------
EventClass
-----------------------
Id
Name
... Other attributes common to every instance
-
-----------------------
TimeSlot
-----------------------
Id
Start
End
-
-----------------------
Place
-----------------------
Id
Name
Address
MaxAttendance
... etc
-
----------------------
EventInstance
-----------------------
Id
EventClassId
TimeSlotId
PlaceId
PresenterName
...Other attributes specific to the instance

EventInstance is a realtionship between EventClass, TimeSlot and Place, any attributes specific to the EventInstance should be stored on that entity. Any attributes common to a related group of events should be stored on the EventClass attribute.

---

Its all a question of Database Normalization, generally speaking, the more normalized the data the better. However, there is a case for compromise when performance is a concern, if the desired data is stored in the output format it does make a select query simpler and faster although, updates might be hell.

I would counteract the case for compromise by suggesting that, with the right Indecies, Materialized Views and, indecies on Materialized Views, you can get the best of both worlds. The maintainability of fully normalized data with the speed of performance. Although, it does require some skill and consideration to get the schema right.