Lisa,
Care to reveal the consultant and the title of his/her book? There are many
"prophets" out there who claim to have the key to the future. In reality it is
their pipe dream that they are trying to pass off as gospel when in fact it is
bull dung. As for an application handling all data integrity I've never heard
one absolutely concrete reason for it, other than the app duhveloper doesn't
have to encode handling for those types of errors when they do occur. Few if
any applications out there will have the luxury of being the only thing to touch
their data. So keep on putting the referential integrity into the database.
It's the only absolute way of knowing that it's followed. Also this meta data
idea is actually VERY old hat. Many a reporting application has been using it
for years (Oracle Discoverer in it's original version had that capability if you
wanted it). The actual idea is to have a user friendly name for a column that
is NOT the computer friendly version duhvelopers like to use.
Sounds like this consultant, whether published or not, is full of it. BTW:
being published does not hold water in my book. Most publishers don't have the
technical staff on hand to validate what the author is saying. So if he
recommends that everyone play Russian Roulette as a way to ease tension and he
has some type of "credentials" then they publish it. Their end desire is $$$ in
the bank, period. When you get a chance, run on down to your friendly Barnes &
Nobel. Peruse the self help and new age sections for plentiful examples. I was
there last weekend, found a book on curing most mental illnesses with
meditation!!
Dick Goulet
____________________Reply Separator____________________
Author: "Lisa R. Clary" <[EMAIL PROTECTED]>
Date: 4/30/2002 11:48 AM
Hi all,
I sort of come from an old school where you should normalize data where you
can (typically 3rd or 2nd) so that you get the efficiency of normalization
but not the difficulty of data extraction. Additionally, I always thought
that putting RI on tables was fairly important (prevention of orphans,
reliable data, etc.) Recently, a consultant who has published a book about
SQL is now telling me that there is a better model--that of value pair
combinations (e.g. variable, value) to which all of the data can be modeled
without the creation of any extra tables. So instead of the 600 tables now
(normalized & with RI) should be broken down into 2 tables--one to hold the
meta data (e.g. variable name and possible values) mapped back to say a
customer table that has a (variable,value,event code,comment) combination
describing everything about that customer. The event code for example might
be 300 - first time customer, 400- wanted removal from mailing list, etc.)
So in theory, I will have very few columns but many more thousands of
records. All integrity would be maintained through an application.
Can anyone comment on this methodology? Supposedly, --according to the
consultant, this is the wave of the future and that "...Oracle Clinicals is
designed in this fashion" . Why would we spend $$$ to have a flat file
design? Am I missing something? I don't want to see this travesty happen to
any of the databases for which I am responsible, but unless I can come up
with something concrete (aside from the textbooks I used in school) ...it
will happen (after all, he is published!) Or maybe someone can tell me where
I can take a course in this style of database modeling.
thanks for your input....
lc
--
Lisa R. Clary
Children's Oncology Group Data Center
104 N. Main Street, Suite 600
Gainesville, FL 32601
(352) 392-5198 x 312
(352) 392-8162 (fax)
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Lisa R. Clary
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
