Re: Another question Regarding ROWID being Safe

In <326F7478.4271_at_cincom.com>, "Brian M. Biggs" <bbiggs_at_cincom.com> writes:
>True, the ROWID is there to provide a unique key, and that key can
>change if the rows move. But, I don't see anything wrong with using it
>to immediately update a row. At the same time, I think it would be
>better to always use the true PRIMARY KEY of the table to update the
>database - it seems like the "proper" way to do it. The problem arises
>when you have tables that don't have primary keys. I know that in a
>perfect relational world, ALL tables should have a primary key, but
>sometimes this just isn't practical.
>
>I never thought about the gateways issue, but that makes sense. If you
>start moving to distributed databases, and gateways to other databases,
>the ROWID idea starts to fall apart. Should you ALWAYS have a primary
>key, artificial or real, on every table no matter what the cost, in
>order to facilitate easier updating?
>
>

The part of this thread that I was responding to was the advice that ROWID is inviolate forever. It is there for use within a transaction, providing a guaranteed unique key for operations that need one. That's all it should ever be used for. Other uses may work very nicely, but when you make use of a feature in an unintended way, you risk future trouble. Its a case of programming by side effect. Whether or not you have or need a unique key in a table is up to you. You can depend on the uniqueness of ROWID, but not its permanence.

And ROWID is an ORACLE concept. If the data moves to another platform, such as a gateway, ROWID may not be there.

Stuart Feigin
Oracle for AS/400 Development
Oracle Corp. Truckee, CA

Of course nothing I write is the official opinion of Oracle Corp. Received on Thu Oct 24 1996 - 00:00:00 CEST