Thanks Tom.

I spent ten years doing SQL in other platforms, then moving to Oracle. While trying to learn how Oracle is different, Tom's books were required reading. Tom provides excellent examples of HOW and WHY. For me, that is essential. Understanding the application of Oracle features enables me to learn. Tom does that better than any other author I've read. So I would recommend Tom's books first to "preload the cache". Then when you read the Oracle docs it is more easily digested.

The last comment reminded me that it'd be great if someone would write a book that teaches SQL Server T-SQL developers how to do what they're used to in Oracle's SQL and PL/SQL, and vice versa. My company's applications need to work with both SQL Server and Oracle, and traditionally that has meant a least-common-denominator approach, meaning that hardly any logic ends up in the database. I much prefer using the database's capabilities where a suitable analogue can be found: a materialized view in Oracle, an indexed view in SQL Server; a unique index in Oracle with the assumption that nulls won't appear in the index, a nonclustered unique index with a predicate excluding nulls in SQL Server; "create table t as select x, y from" in Oracle, "select x, y into t from" in SQL Server. And so on.

The struggle is that it takes a while of digging to figure out the best way to do things. SQL Server users accustomed to using #temporary tables would do well to search this site to understand how to accomplish their goals better in Oracle; Oracle users accustomed to PL/SQL packages who still want well-organized stored procedures in SQL Server should... well, I'm still trying to figure that one out. I wish there was a book on the subject.

Hi David,

There are two books on the subject, the PLSQL guide from Oracle and the stored procedure guide from SQL Server. Then the statement is, have all your code go through stored procedures. And, I'm not trying to be flippant. Think of the database as one big method invocator where you go ask it to do something and it does it for you.

What drives me nuts is that stored procedures are so much more how java wants things, not straight sql. Composing english sentences in a programming language is just not very pretty, but the java crowd continues to scream they need direct access. I blame the object/relational mapping world, like hibernate. Those arrogant developers decided that the OR layer needed direct access to tables. If those guys instead designed (and I mean from the ground up) to deal with stored procs, then, vhalla, you'd be all set.