Databases Reference
In-Depth Information
proposals on this particular issue. I'll come back and revisit this possibility at the very end of the
subsection immediately following. First, however, let me try to explain my own position.
Symmetry
I believe symmetry is a good design principle in general. To quote Polya:
“If a problem is symmetric in some ways we may derive some profit from noticing its
interchangeable parts and it often pays to treat those parts which play the same role in the
same fashion ... Try to treat symmetrically what is symmetrical, and do not destroy
wantonly any natural symmetry” (George Polya:
How To Solve It
, 2nd ed., Princeton
University Press, 1971).
“We expect that any symmetry found in the data and condition of the problem will be
mirrored by the solution ... Symmetry should result from symmetry” (George Polya:
Mathematical Discovery: On Understanding, Learning, and Teaching Problem Solving
,
2nd ed., John Wiley & Sons, 1981).
Aside:
Polya also articulates in this latter topic what he calls
The Principle of
Nonsufficient Reason:
“No [solution] should be favored of eligible possibilities among
which there is no sufficient reason to choose.” Some might appeal to this principle as a
basis for rejecting deletes on join views entirely: at least, join views like the one currently
under discussion. To me, however, that position is too extreme; it throws the baby out
with the bathwater, as it were. Let me continue to present what I regard as good reasons—
well, fairly good reasons, anyway—for not taking such a drastic step but, rather, going
with option 3.
End of aside.
In my experience, asymmetry often means we've got something wrong. At the very least,
it can lead to counterintuitive behavior, behavior that can seem capricious and, precisely for that
reason, hard to understand, teach, learn, and remember. In the case at hand, an asymmetric
solution would mean cascading deletes on S to ST but not SC (option 1) or the other way around
(option 2). This arbitrariness has at least two unpleasant consequences. First, it means the DBA,
or some other human agency, might to have to get involved in order to choose between the two
options (without, I might add, any good guidelines to help in making that choice, in general).
Second, it raises the possibility that a view defined as ST JOIN SC and one defined as SC JOIN
ST might have different update behavior, a state of affairs that's surely undesirable. So I think
considerations of symmetry alone are sufficient to make options 1 and 2 nonstarters.
I observe further that options 1 and 2 are actually the wrong choice if assumption (a) is in
fact the right one. That is, options 1 and 2—and assumption (b)—are a safe way to go only if it's
definitely the case that a supplier can have a status but no city or vice versa. But the DBMS
doesn't
and can't
know that such is definitely the case if all it knows is that S = ST JOIN SC.
