Quote:
Originally Posted by carlosn
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?