Re: Database Normalization-Outdated?

Too funny!

The first problem that comes to mind is duhvelopers:

There are a lot of developers that would simply be incapable of dealing with Meta Data for every day queries. We tried to use some very flexible meta data in a DW, and it turned out to be too hard for the developers to grasp, many of whom were quite good.

So all data administration will come down to maintaining event codes in a single table. I know a few DA's that would likely disagree with this. :)

This is a damagers dream: buy a SAN with one filesystem striped across the whole box, build one table to hold all of the data. PHB's will love it.

DBA's? What DBA's? We don't *need* no *stinking* DBA's!

May we have the consultants name and the Title of the book?

It would be much easier to shoot this full of holes on a point by point basis.

Jared

"Lisa R. Clary" <lisa_at_cog.ufl.edu>
Sent by: root_at_fatcity.com
04/30/2002 12:48 PM
Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        Database Normalization-Outdated?

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: 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: 
  INET: Jared.Still_at_radisys.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).