Re: ROWID's (fwd)

Cheryl Kendricks wrote: > ---- Message of Why NOT to --- > I say good because it insure that you follow RI. Every table must have a > UNIQUE PRIMARY KEY. IF you fetch for that PRIMARY KEY you return back > exactly the row you want. The use of how I have found many of my > programmers using ROWID, works around defining PRIMARY KEYS. This is why I > am for it's non-usage. It's like allowing me access to create a table > using the HEX TABLE name verse the actual table name. > ------------------------------------------------------------------------ > > Cheryl, Some tables cannot have UNIQUE PRIMARY KEYS because of the nature of the table or the version of the data base. I could be mistaken, but using PRIMARY KEY <definitions> were not a part of INFORMIX data bases, until after 4.1, except in how you designed a data base with good sense "primary keys" of your own making. I'm looking through the 4.+ manuals as we speak, and do not see this as part of the CREATE TABLE syntax. Only good sense in data base design is used. Constraints arepossible but not the same intent. But I'm sure someone out there knows the answer better than I. And it's a no-brainer to put a serial column on every table. But there are indeed tables in many databases throughout webland that do not follow RI or any rules. You're right, using a better way is always the better way. It's only been recently that UNIX boxes have run faster, and how soon we forget the difference in performance from even 5 years ago. Adding one index too many was enough to turn many machines into dogs ( and still is ). This is no excuse now, and your comments are well intended and good. :-) -- \\\\|// (6 6) ==============================---o00--(_)--00o---============================ Tim Schaefer tschaefe@encore.com tschaefe@shadow.net Encore Computer Corp http://www.shadow.net/~tschaefe =============================================================================