Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database Normalization-Outdated?
Lisa - not sure i follow the specific example, but i say RI is still a
wonderful feature of an RDBMS and should not be thrown out. Many package
apps have not implemented RI because they run on many RDBMS platforms, and
each handles RI differently. So put the RI in the app they say - right!
Not fun when the app forgets. I've seen some real messed up PeopleSoft
data.
Codd was a smart guy. I'd stick to my guns if i were you. Don't have any bleeding edge white papers to support the argument, but we're building a new app with cool tools (java, app servers, & oracle db). Guess what - the Db is still normalized.
Then again, maybe I'm just an old curmudgeon - i am nearly 40 now.
-----Original Message-----
Sent: Tuesday, April 30, 2002 2:49 PM
To: Multiple recipients of list ORACLE-L
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 32601Received on Tue Apr 30 2002 - 15:59:08 CDT
(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: lisa_at_cog.ufl.edu 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: ListGuru_at_fatcity.com (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: STEVE OLLIG INET: sollig_at_lifetouch.com 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: ListGuru_at_fatcity.com (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).
![]() |
![]() |