OOW2K7: First sessions

I'm afraid I skipped the opening keynote of the conference in favour of breakfast with Doug Burns and Dmitri Geilis. It was almost certainly more entertaining and more educational.

My first session of OpenWorld was Dr Paul Dorsey on the "Thick" database. That's thick as in full of business logic rather than stupid. Quite why it's not "rich" database like thin client vs rich client I don't know. Paul said his motivation was to annoy people, which was promising. Unfortunately the sort of people he wanted to annoy - OO programmers, J2EE and .NET middle tier evangelists and open source bigots - weren't in the audience. This is an Oracle conference, so pretty much everybody is going to be signed up at least to the idea of proprietary framework , and most of them will be in favour of putting most if not all the business logic in PL/SQL. Although, as he acidly observed, OTN has drunk the SOA Kool-Aid.

The point being that UI standards change far more often than the database does. So it is acually more important to be UI independent than database independent. He also said that ApEx is not - out of the box - a thick database implementation. It is a product and it is possible to build ApEx applications in a dumb fashion. However, the cost of being dumb in ApEx is less than being dumb in Java.

The second half of the presentation was devoted to an overview of techniques for building thick database APIs. This covered table() functions, Views with Instead-Of Triggers, PL/SQL collections and bulk operations. I'm afraid I found this a bit of a waste of time because surely this is all old hat? But apparently not. At least one person in the audience didn't know about bulk exception handling and so is obviously not using FORALL statements.

Funnily enough, the next session also dealt with building PL/SQL wrappers for SQL, but coming from a different angle. This was Steven Feuerstein, who was seeking to cure our addiction to writing SQL with his "code therapy". His basic arguement is that we should not proliferate SQL statements throughout our programs. Rather we should encapsulate SQL in reusable functions which have proper exception handling and well-structured naming conventions. We should think of SQL in PL/SQL functions as a service which is provided to the actual application code.

We should generate these functions because that's the only way to ensure that proper standards are enforced. Especially in naming conventions, which must be adhered to if the functions are to be reused. I would say that this presentation was an advertisement for the Quest CodeGen utility, except that they're giving it away for free. Steven had one phrase I really liked: deja vu coding. This is when we find ourselves coding the same thing we coded last week. That's a definite sign we have a piece of functionality we really ought to extract to an API for reuse. Of course, the OO crowd, especially the XP lot, have been banging this particular drum for years.

Following on from Steven was Bryn Llewellyn with his session on PL/SQL New Features in 11g. He kicked off with the fine grained dependency tracking: I'm not sure I would have started there, as it's not exactly the most exciting new feature. But I liked his explanation of why Oracle had the validation checking in the first place: it's in lieu of a make file. Real Native Compilation is much more interesting. Until 10g Oracle had "outsourced" the compilation to a C compiler on the OS, because it was easier for Oracle. Unfortunately many sites wouldn't install a C compiler on their production box, so they couldn't take advantage of the performance benefits. I currently work on such a system: the security policy forbids it. Yes this does mean our external C procs are probably sub-optimally compiled but you can't argue with the security policy. So this feature will be very useful to us.

There's also Intra-Unit inlining, which basically counteracts the performance of Feuerstein-approved modularity by duplicating the code from called functions at the compile stage. Result set caching has already been widely talked about. As Bryn says, "You can never have too many caches." His test cases went from ~1000 milliseconds to 0 milliseconds. But apparently not every query will improve by a factor of infinity. The results are guaranteed to be correct in every case but this means that the benefits of caching results may not always be high. Obviously there's a cost to invalidating the cache. What else? DBMS_SQL is here to stay, but only for Method 4 queries. That is when we don't know either the number of defines (selected columns) or the number of binds. For everything else we can now use EXECUTE IMMEDIATE. In case you're wondering, there is no Method 1, 2 or 3.

They are closing the internet village now, so it's time to sign off.