Re: Using rowid in a html anchor / select statement

In article <32519e00.2351871_at_dcsun4>, Thomas J. Kyte <tkyte_at_us.oracle.com> wrote:
>
>But rowids don't change.
>
>A rowid can be reused. It cannot be changed. A rowid is like a primary key
>assigned by the system when the data is inserted. If you exp the data, truncate
>the table and re-import, the system will assign a primary key to the data. You
>are not changing a rowid, you are deleting and re-inserting your data.

I don't know about you, but when I export and import data, in most cases I don't consider that "new data" that somehow deserves all new primary keys. It would also mean that any relationships within the set of data that I exported and imported would be broken. Generally, if you join tables A and B and get one result, I'd hope you'd get the same result after you exported and imported tables A and B. If you use rowids, that won't happen.

Using rowids just goes against the whole nature of relational database theory. The primary key of a record should not depend on how the record is physically stored in the database. The identity of a record is supposed to be defined by its contents, not how those contents are represented. It should not be affected if those contents are exported and re-imported. Using the rowid as a primary key is kind of like doing all your string comparisons in C just by looking at the char* pointers to the string. Sure that's a lot faster, but you're not really comparing the strings. You're just looking to see if the string is stored in memory at a particular location. You might very well have the same string stored in a different location, and you may have stored a different string in the same location at some point.

As a matter of fact, I was just looking up something in the Oracle7 SQL Reference Manual (Release 7.3), and I noticed the following on page 2-42:

    "A ROWID does not change during the lifetime of its row. However,     you should not use ROWID as a table's primary key."

--
Steve Kanefsky