-----Original Message-----
From: Whittle Jerome Contr NCI [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 10:09 AM
To: [EMAIL PROTECTED]
Cc: April Wells
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?April,
I'll go one better. We don't even have unique indexes much less primary keys and foreign keys. Only about 20 percent of the tables have unique indexes. A few others do have primary keys but they are used really just as unique indexes without FKs. Basically they just pour data from one table into another; do some manipulation; run a report; pour the data into another table; run a report; and so on. This project has been around since the early '80s and they just keep moving it into difference containers like Oracle every few years.
We did set up one new project with PK / FK relationships on a few tables. The developers, some who've been on this project for decades, just can't grasp it. I've even offered to lend them my copy of Database Design for Mere Mortals as a place to start. They just want to add more columns to existing tables. We might get a contract to rebuild it from scratch. I've already gone on record that none of the current developers should not be on the rebuild project. They are not happy with me to say the least.
Jerry Whittle
-----Original Message-----
From: April Wells [SMTP:[EMAIL PROTECTED]
<< snip >>
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 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. |
