I have no problem hiding irrelevant complexity. But it has to be
understood, and hidden in an appropriate way so that your assumption that
the result is correct will always be safe.
In an ideal DBMS much complexity could be safely hidden inside suitable
datatypes. Of course many/most SQL implementations have very limited
support for complex types. But even so, we do seem to have an urge to
introduce spurious complexity even when SQL doesn't impose it on use. For
example, I don't think I've ever seen a database where the internal fine
structure of a postal address wasn't layed out in all it's irrelevant glory.
I can see why in many businesses you'd want to know the postal code, but the
rest of it is usually irrelevant to anyone but the posty walking the route.
(And just to be clear, I am sure that there are obscure applications for
which one does need to model the fine structure of the postal address,
perhaps down to the level of the forward sortation area and local delivery
unit. My point is that much complexity I see is not really dictated by the
enterprise of interest at all but is either thoughtlessly introduced, or
introduced "just in case" by rogue designers. Which is ironic since so many
would probably then also claim to want to minimize the number of tables "to
reduce complexity".)
Roy
PS: This is a particularly sore point with me because my address is strange.
As a result I regularly have trouble using Internet shopping sites, the GPS
in my car can't be told where I live, and I recently had a credit card
application declined because they couldn't match my address to some register
or other. In all cases it was because a bunch of database designers got
right up themselves modelling irrelevant complexities thus making everyone's
life much harder.
I'm over it now.
Really.
