ROWID
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.
JDBC4 RowId
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.
|