Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> AW: Database Modeling- Normalization - Dinosaurs or What?

AW: Database Modeling- Normalization - Dinosaurs or What?

From: Stefan Jahnke <>
Date: Fri, 28 Mar 2003 02:23:41 -0800
Message-ID: <>


What I don't understand is: If your development department want to go with a VSAM like approach, why do they invest in Oracle. Why not just get a zSeries and stick to VSAM or IMS ?  

PS: Your working environment sounds like an actual implementation of Purgatory  


Stefan Jahnke
BOV Aktiengesellschaft
Voice: +49 201 - 4513-298
Fax: +49 201 - 4513-149
Please remove nospam to contact me via email.

visit our website: <> subscribe to our newsletter: <>

Sicherheitsluecken mit IT-Security-Konzepten von BOV effizient schliessen! Weitere Informationen unter +49 201/45 13-240 oder E-Mail an <> .

Wie Sie wissen, koennen ueber das Internet versandte E-Mails leicht unter fremden Namen erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um Verstaendnis dafuer, dass wir zu Ihrem und unserem Schutz die rechtliche Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen ausschliessen.

As you are probably aware, e-mails sent via the Internet can easily be copied or manipulated by third parties. For this reason we would ask for your understanding that, for your own protection and ours, we must decline all legal responsibility for the validity of the statements and comments given above.

-----Ursprüngliche Nachricht-----
Von: April Wells [] Gesendet: Dienstag, 25. März 2003 14:09
An: Multiple recipients of list ORACLE-L Betreff: RE: Database Modeling- Normalization - Dinosaurs or What?

Hi Paula  

Hey... I live in your world.  

Our "data warehouse" was designed by someone who had never dealt with ANYTHING relational... but based it on VSAM files and tried to make the leap.
We have a table with 873 columns in our data warehouse... they call it a FACT table. It has client name and address (well... they are "facts", right... ?).  

You don't have foreign keys... we don't have PRIMARY keys. We call unique indexes primary keys... but after 10 years of not understanding why queries didn't return data that made sense, they allowed me to put not null constraints on the columns in the unique index (when I told them that they either do that or they answer to the clients). Historically, the DBAs in this company have done little more than implement what programmers designed and then tried to make it work. They WON'T use stored procedures, they don't understand them. THEY write code that sits in files on the OS and call those "programs" via shell scripts. They heard once that it was faster that way in Oracle 2 and so it must be still true, cause COBOL never changes so Oracle must not change.  

The part I like best, though, is... we have a ONE column table with ONE row... SystemDate... because they can't figure how to get sysdate from dual into a variable and use it in their programs... so they start their data warehouse load run with a truncate to that table, and an insert of the date passed in from the OS so they can load the DW tables.  

DON'T stop fighting. I think that is what they want. I have been told (in meetings where I have been requested for my DBA input) to sit down and shut up unless I am asked a question when I tried to point out things like... you can't have 1500 columns in a table no matter how fast it will make the queries fly... you can't have table names of 72 characters for descriptive sake... you really can't call a column DATE just because that is what is in it, an arbitrary date... Make them hear you even if they don't listen. Be the biggest pain they can imagine, eventually it will slowly start to pay off, because eventually they will realize (again VERY slowly) that you are right. It is how I got the reputation of being a DBA (Dat Bi#$h April)  


-----Original Message-----
Sent: Monday, March 24, 2003 6:14 PM
To: Multiple recipients of list ORACLE-L


The emphasis in many places I have worked is developing quick and dirty systems as quickly as possible and working with developers that don't seem to have very much understanding of Relational Database Theory but who prefer to program using flat files in relational databases - calling it "object-oriented" when it truly is not. Let us just say that it is highly denormalized. As a DBA I care about data integrity, extensibility and scalability but the up and coming esp. SQL Server developer types seem to operate in a world where this doesn't matter - just buy more hardware, denormalize to make the programming easier, etc.

I have been losing this battle.

So - what is your experience with this?

What about the idea of having everyone access all objects in the views so that if need be the DBA's could in fact still make physical changes to the schemas without a large amount of rewriting of code? - as a standard

Living without normalization for most things - esp. small systems and w/o fk's except as they are maintained in the application for the sake of getting the application done quickly, cheaply.

It turns my stomach but then I wonder about my own sanity - am I making too much out of nothing? What about these stovepipe systems?

Case in-point 100,000 row table for asset management - moving different types of addresses to a separate address table and moving different types of people to a person table. Developers are aghast at the performance implications. I am thinking perf. implications not real esp. with small amount but provides extensibility and RI with these reference tables instead of denorma. in multiple tables. They say mostly batch inserts/updates and batch reads - but then they say some OLTP. This is a SQL Server database. I think the separate reference tables provides only way for extensibility and data integrity. I say I will write for them a joined view. They say perf. implications. - AARRRGGHH!

Oracle OCP DBA

The information contained in this communication, including attachments, is strictly

confidential and for the intended use of the addressee only; it may also contain

proprietary, price sensitive, or legally privileged information. Notice is hereby given that

any disclosure, distribution, dissemination, use, or copying of the information by anyone

other than the intended recipient is strictly prohibited and may be illegal. If you have

received this communication in error, please notify the sender immediately by reply e-mail,

delete this communication, and destroy all copies.  

Corporate Systems, Inc. has taken reasonable precautions to ensure that any attachment to

this e-mail has been swept for viruses. We specifically disclaim all liability and will

accept no responsibility for any damage sustained as a result of software viruses and advise

you to carry out your own virus checks before opening any attachment.  


Please see the official ORACLE-L FAQ:

Author: Stefan Jahnke

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message to: (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). Received on Fri Mar 28 2003 - 04:23:41 CST

Original text of this message