Oracle ROWID - physical location in Database

If you are familiar with Oracle you will probably heard about its ROWID. Essentially it represents the physical location of a row in the database and can be used as faster option compared with the primary key.

SQL> select rowid, id, title from f_topic where id = 1;

ROWID                 ID  TITLE
AAADW8AAEAAAAF3AAA    1   Why is it called Ebean?

SQL> update f_topic set title='modified title'
  3  where rowid = 'AAADW8AAEAAAAF3AAA';

1 row updated.

SQL> select rowid, id, title from f_topic where id = 1;

ROWID                 ID  TITLE
AAADW8AAEAAAAF3AAA    1   modified title

At the ASK TOM website there is a discussion on ROWID and when it can be used.

Why a Physical ROWID is interesting for ORM

In ORM we perform our updates and deletes using the Id property in the where clause. Now if we used Oracles ROWID (or equivalent) we would get a decent performance gain for these updates and deletes and that's pretty obvious.

Additionally in ORM we have the potential to navigate Object graphs and by using lazy loading we are transparently fetching data from the database.

If instead of using the Id we used the Physical ROWID this starts to sound close to OODBMS behaviour if you relate the Physical ROWID to a OODBMS pointer.

For people who are looking to use ORM in fairly OODBMS fashion with lots of lazy loading this could be interesting. Specifically you could just walk the Object graph and the objects are materialised out of the database transparently and quite efficiently.

Using ROWID Transparently in Ebean

With Ebean Lazy Loading occurs on demand (transparently) as you walk the object graph. The use of such ROWID's could be completely transparent to the user of Ebean.

In general if a database had ROWID support I would look to fetch it and store it on the EntityBeanIntercept. It is then available for updates and deletes without an issue.

For using a ROWID for lazy loading of a bean there is an interesting issue. That is, that the ROWIDs you want (unlike the foreign keys) are actually on another table and would potentially require a join to get them. If this is the case then you are matching up the cost of the additional join against the performance benefit of using the ROWID to lazy load.

Now if you have thoughts or ideas on this I'd love to hear about it but currently I'd guess and say the join overhead would be higher than the faster lazy loading. However, there may be a ways around that.


In the JDBC4 specification rowId is potentially becoming part of the standard. However, it is unclear to me if JDBC4 rowId is going to be useful for what I want it for.

Which Databases have a Physical ROWID

As far as I'm aware only Oracle exposes a Physical ROWID. JDBC4 may well have got me excited over nothing :(

Thinking longer term, and considering using ORM/RDBMS in a more transparent OO fashion then I'd guess and say that more Databases will introduce something resembling a Physical ROWID. As they say, time will tell.

Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements