RE: ROWIDs ???
Correct me if I am wrong. AFAIK "Alter table add rowids" on fragmented tables will be unique. Agreed, rowids is not a good practice. -----Original Message----- From: Murray Wood [mailto:murray@quanta.co.nz] Sent: Wednesday, 10 January, 2001 1:26 AM To: informix-list@iiug.org Subject: RE: ROWIDs ??? Correct this is not good practice. Far better to use the primary key, or a unique key / index when it exists. Moreover (with fragmentation) rowid may not be unique. -----Original Message----- From: owner-informix-list@iiug.iiug.org [mailto:owner-informix-list@iiug.iiug.org]On Behalf Of Lucky Leavell [RIS] Sent: Wednesday, January 10, 2001 2:58 AM To: informix-list@iiug.org Subject: ROWIDs ??? Version 7.31 OS: AIX 4.3.3 I am fairly new to the Informix 4GL world and notice a lot of the extant programs use ROWID to access/update rows in tables. Is this considered a good programming practice? (Ingres had the concept of TIDs - tuple IDs - but dtrongly recommended against their use.) It would seem to be a better practice to use a primary key (e.g., employee number) instead... comments? Thank you, Lucky Lucky Leavell Phone: (800) 481-2393 or (812) 366-4066 UniXpress - Your Source for SCO FAX: (888) 231-9640 or (812) 366-3618 1560 Zoar Church Road NE Email: lucky@UniXpress.com Corydon, IN 47112-7374 WWW Home Page: http://www.UniXpress.com
Hannes Visagie wrote in message <93gul8$45j$1@news.xmission.com>... > >Correct me if I am wrong. >AFAIK "Alter table add rowids" on fragmented tables will be unique. > >Agreed, rowids is not a good practice. > Yup - they are guaranteed to behave like traditional Informix rowids, but they seem to be implemented with a kind of upside-down index, and thus consume space that isn't used for rowid's on non-fragmented tables. No doubt these rowids also waste time as well. Speaking from total utter ignorance of the engine internals here, I don't know why they couldn't just hash up something unique across the fragments without too much trouble.
Andrew Hamm wrote: > Hannes Visagie wrote in message <93gul8$45j$1@news.xmission.com>... > > > >Correct me if I am wrong. > >AFAIK "Alter table add rowids" on fragmented tables will be unique. > > > >Agreed, rowids is not a good practice. > > > Yup - they are guaranteed to behave like traditional Informix rowids, Nearly; they are more stable than traditional ROWIDs, not being changed when you do an ALTER INDEX xyz TO CLUSTER whereas traditional rowids certainly are affected by that. > but > they seem to be implemented with a kind of upside-down index, and thus > consume space that isn't used for rowid's on non-fragmented tables. No doubt > these rowids also waste time as well. They are a physical column and they do indeed occupy space (both in data and in an actual index, whereas traditional rowids are a virtual column occupying no space in the data or in any index) and time. > Speaking from total utter ignorance of the engine internals here, I don't > know why they couldn't just hash up something unique across the fragments > without too much trouble. Ultimately, because there can be more than 2^31-1 rows in a fragmented table, but a rowid can only have 2^31-1 distinct values. There are other reasons too, but... -- Jonathan Leffler (jleffler@earthlink.net, jleffler@informix.com) Guardian of DBD::Informix 1.00.PC1 -- see http://www.cpan.org/ #include <disclaimer.h>