View Single Post
  #2 (permalink)  
Old 08-18-10, 12:16
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
Quote:
Originally Posted by carlosn View Post
So I've set up additional tables event_maintenance, event_delivery, etc.

I set up the tables such that:
Event.PK = Event_SUBTYPE.FK (for each subtype table)

The problem is that now I can have multiple subtype rows associated with one event, which doesn't make sense.
well, it actually does, although i think i can see the confusion

an event can have any event subtype, and in practice, your application logic would ensure that a subtype row is created only in the correct subtype table and none other (it wouldn't make sense for an event which is a delivery to have rows in both the delivery subtype table and the maintenance subtype table)

there are ways that you can enforce this in the database but they are a bit complex, and if you are okay with letting application logic do it, then i am too

as an aside, consider if you didn't have subtype tables at all, but had one master table with nullable fields for all the different subtype columns... do you normally have application logic to ensure that only the correct set of subtype columns and no others are populated by the application? because that's ~really~ hard to do in the database

anyhow, the other side of this question is retrieving data from subtype tables, and that's either done in two queries (get the event, find out what type it is, and query the appropriate subtype table) or one query with as many LEFT OUTER JOINs as there are subtypes

incidentally, what you get back from the single query with all the LEFT OUTER JOINs is a record set that looks exactly like the single master table with all the nullable columns

helps?
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote