Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!tmp From: tmp@mentor.cc.purdue.edu (Tom Putnam) Newsgroups: comp.databases Subject: Re: how to implement cursor based UPDATE/DELETE Message-ID: <12455@mentor.cc.purdue.edu> Date: 17 May 91 14:40:09 GMT Article-I.D.: mentor.12455 References: <22637@shlump.lkg.dec.com> <24356@oolong.la.locus.com> Reply-To: tmp@mentor.cc.purdue.edu (Tom Putnam) Distribution: comp Organization: Purdue University Lines: 41 As a relative novice to SQL, my original reply on this question has certainly raised some interesting discussion. I must say I have been pleased to note the overall tone that all of us seem to be trying to achieve independence of our applications from the physical structure of the databse. In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >... >This is the meaning of physical abstraction, so Kyle's point is not off >target. Kyle's point is that ROWID is a physical implementation in that it >places an order on relations which are, by definition, unordered. I don't recall who said it, but ROWID as used in my example in fact implies no physical ordering. It is conceptually a unique value which somehow gives unique access to a record. Yes, one could say to oneself "I know ROWID as implemented in this version of is in fact the physical row number of the record within the file." The ways people talk about using such unique identifiers seem to reflect their understanding that the ROWID does not require some kind of unique index data structure to exist. But the use I made did not interpret the value of ROWID in any way, nor do I think it ..."places an order on relations which are, by definition, unordered." As I mentioned to several of you in off-line mail, I am still uncomfortable with its use. It is probably because I know that I can use ROWID to more or less "physically" gain direct access to a record without having to use an index which depends upon a value which is explicitly in each record. So I am taking advantage of implementation knowledge that tells me this is probably much more efficient than writing the update statement with a bunch of WHERE clauses that uniquely but less-efficiently defines the record. By the way, I understand that some (older?) versions of Informix maintainted ROWIDs using SMALLINT data type which created all kinds of grief if the database exceeded 32767 records :-( The current version 4.0 uses type INTEGER so we don't run into trouble until we exceed 2,147,483,647 records. That should give me a couple more weeks to worry about it :-) -- Tom Putnam Assistant Director Internet: tmp@mentor.cc.Purdue.EDU Purdue University Computing Center BITNET: TMP@PURCCVM Mathematical Sciences Bldg. Phone: (317) 494-1787 West Lafayette, IN 47907