Re: ROWID's (fwd)
Posted in 1996
Cheryl Kendricks wrote: > > Thanks Tim! Hope you do not get offend by me posting this on the list! Yet > this is the only way I car reply to you: > If you do not have UNIQUE PRIMARY KEYS then you do not have a > Relational DB (You have a DB with a bunch of Tables with a bunch of data). > I say go back and clean up the design and fix that DB. It may not be > defined by the INFORMIX DB, but it should be defined in design and applied > via indexes by always having a UNIQUE index on every table in your DB. If > YOUR DB designer's are designing DB(s) this way I suggest you hand them > a Relational Data Base Design Book. > > I'v implemented a rule "That I WILL PROTEST building any DB on my Informix > 7.X system that do not have an UNIQUE PRIMARY KEYS defined for EACH > TABLE." > ------------------------------------------------------------------------- > Cheryl Kendricks > Internet:cherylk@prod1.jcdc.doleta.gov > OR > kendric@gwysmtp.jcdc.doleta.gov > DTSI, Inc. Voice: 1-800-598-5008 > Database Administrator - DOL Job Corps San Marcos, Texas > ------------------------------------------------------------------------ No offense taken. :-) ALL <--count 'em ALL the data bases I work on are ABSENT OF UNIQUE PRIMARY KEYS. They are incapapble of such a feat, except through unnatural means. ( magic ) I have worked on 7.1 data bases, 5.0 data bases, and am currently supporting 4.1 data bases. Yes 4.1 data bases persist. They're organic or something, and just won't die. They just keep chuggin along. This is actually a good thing, now that I've learned Netscape has bundled Windows NT INFORMIX Workgroup Server, so we can migrate everything to an intranet, rewrite our 4GL in Java and Crystal Reports, skip 7.1 on UNIX, and retire in the Caymans. Life is good. To clean up these data bases is ALSO IMPOSSIBLE. They are legacy systems that have sprouted legs, and branches like a banyan tree, and cannot be modified without a team of scientists coming in, shutting down the company, and changing them. There are also ( rather quietly ) CURRENT commercial distributed software applications in 4GL that DO NOT HAVE UNIQUE PRIMARY KEYS. I see them as we speak. Make no mistake, your suggestions are noble, and worthy of great praise and adoration. But the real world just goes on. And so do databases without every table having UNIQUE PRIMARY KEYS. Not EVERY table should have UPK's even if the option is available. As a developer in the group I work in, we know all about good relational design, and allow a good pecking on the head for silly design. But the business I support, a computer manufacturer, also has had many EE types build some of the legacy systems outside MIS. Then like many folks just trying to run a business, they purchased outside software, which too is/was of questionable design. We even have some MAJOR Standard Engine legacy systems, where the data set is HUGE. And accounting systems that twist the mind. But to try to enforce the IDEAL is pointless. We've got reports to write, third-party software to support, and users to annoy--er support. But to change all that? What are you crazy? This is modern business reality. Excuse me now, I'll have another sip of coffee, read the Dilbert for the day and get another twisted report out. I'm workin' on my retirement you know. Imagine wanting to change all that! :-) Tim -- \\\\|// (6 6) ==============================---o00--(_)--00o---============================ Tim Schaefer tschaefe@encore.com tschaefe@shadow.net Encore Computer Corp http://www.shadow.net/~tschaefe =============================================================================