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.
