"Maybe a directory would be better"?! This is throwing the baby out with the bath water. Never mind that the industry supposedly figured out that hierarchical data stores where a bad idea 30+ years ago (yet they still persist... excuse the pun), changing data models is not going to solve the age-old problems concerning missing data. These problems have to do with fundamental logic and predate computers.
The more rigid relational design (with dead people in a separate table from all people) has several advantages including presenting clearer meaning... not just to the user but to the system. Note that the base tables involved can always be re-combined in a view to hide the "complexity" of having multiple tables from the logical perspective. Introducing nullable columns shifts what starts as a design problem, back to an implementation problem. In the case of the death date in the person table, the person table can no longer be "trusted" to state a single thing and must always be tested for what it means (is this person dead... if so).
As for performance... these are entirely logical issues so how can we even address performance without talking about a specific system. This said, lest someone assert that *no* DBMS will perform as well in the join case, let me note that: a) the assumption is that in general, users want to see the death information for a person, if the converse is true (and it probably is for all but the most morbid of applications) then retrieving only the person information will perform better on most systems; b) I have seen at least one DBMS with an architecture that allows it to performs just as well when joining tables as when selecting from base tables.
Slashdot Mirror
"Maybe a directory would be better"?! This is throwing the baby out with the bath water. Never mind that the industry supposedly figured out that hierarchical data stores where a bad idea 30+ years ago (yet they still persist... excuse the pun), changing data models is not going to solve the age-old problems concerning missing data. These problems have to do with fundamental logic and predate computers.
The more rigid relational design (with dead people in a separate table from all people) has several advantages including presenting clearer meaning... not just to the user but to the system. Note that the base tables involved can always be re-combined in a view to hide the "complexity" of having multiple tables from the logical perspective. Introducing nullable columns shifts what starts as a design problem, back to an implementation problem. In the case of the death date in the person table, the person table can no longer be "trusted" to state a single thing and must always be tested for what it means (is this person dead... if so).
As for performance... these are entirely logical issues so how can we even address performance without talking about a specific system. This said, lest someone assert that *no* DBMS will perform as well in the join case, let me note that: a) the assumption is that in general, users want to see the death information for a person, if the converse is true (and it probably is for all but the most morbid of applications) then retrieving only the person information will perform better on most systems; b) I have seen at least one DBMS with an architecture that allows it to performs just as well when joining tables as when selecting from base tables.