From: DW
To: Editor
The following exchange recently was posted on your old
stomping ground. Pat Phelan, who they are now passing off as their resident
database expert, provided the answer.
Q: We are weighing the pros and cons of building four
applications' data on a big consolidated schema (catalog in MS SQL Server) or
each application has its own schema. One team insists the centralized approach
will be the easier way for sharing common data between four applications. The
other team insists the centralized approach will be more complex for tables
maintenances especially when it comes to application version upgrade.
A: I would STRONGLY suggest that you keep separate catalogs, one
for each application. My reasoning for this is that it is always easy to
combine data, but it is normally much harder to separate it once it has been
commingled! In MS SQL Server, this would correspond to four separate databases.
Once again, an 'expert' confuses the application and the
logical database levels.
From: Fabian Pascal
To: DW
That is likely true, however (a) it is quite possible to
express the same situation in language which does not confuse the two (b) it is
in the context of a product, so it may well be that the product forces such
solutions.
I've seen much worse.
From: DW
Thanks for the timely reply. After reading more of the
articles that Mr. Phelan wrote, that was a minor error indeed. His more serious
lapses in judgment involve OODBMSs (which he considers superior to RDBMSs),
subtype/supertype entity relationships (he actually advocated table
denormalization when a subtype entity would suffice), reliance on applications
for integrity enforcement, and an unabashed belief that Oracle et al. are
RDBMSs. I subscribed to the searchdatabase.com in order to get your column,
since you've been forced out all they send are dribblers like Phelan and
product ads passed off as white papers. Thank God for DATABASE DEBUNKINGS.
From: Fabian Pascal
It was predictable and I said so in my writings, that this
would be the follow-up to terminating my column, because both the termination
and the choice of a new “expert” are rooted in the same ignorance of
fundamentals and the conjunction (and conflict) of interests between the media
and vendors to focus on products and ignore fundamentals as "theory"
and, thus, not practical. Since most practitioners are products (pun intended)
of this system, which does not require them to know fundamentals, they are
ignorant too and, thus, there is nothing to move the industry towards
education, as distinct from training and sheer “experience”. As I say in my
lectures and seminars, a problem without a solution.
Ed. Comment: Betcha Phelan, unlike me, won’t have a
problem with sponsors, which is what his kind of material is geared for.
One of Codd’s main objectives for the relational model was to
facilitate the distribution, redistribution and merging of database schemas! It
is precisely because SQL products are not truly relational that they
cannot do a good job of that, forcing the kind of limitations advocated by
so-called “database experts” like Phelan. What is more, because nobody realizes
this, the correct product improvements are not likely.
Incidentally: god has nothing to do with dbdebunk.com, and
vice-versa.
Posted
02/21/03
[ABOUT]
[QUOTES]
[LINKS]
