Friday, November 17, 2006

UKOUG 2006: Day Three

Just after I finished writing up Wednesday I met Mark Rittman. He was still shellshocked from discovering that his ISP had failed to back up his site properly and so he had lost three years worth of blogs, articles and other stuff. This is not just gutting for Mark, it is a loss of a major web resource for us all. By Thursday he had become more philosophical: the forcible purge of the site at least gives him an opportunity to reassess what he does with it and cleared away some of his more embarrassing early posts. Not that I'm sure Mark had much to be embarrassed about. Anyway, in future he will be adopting a belt and braces approach to backing up his articles. A lesson for us all.


I was actually on leave on Thursday. So I only attended a couple of sessions in the morning and made a last tour of the exhibition hall before coming back to London.

The first session I attended was Mike Hichwa, the Oracle VP for SQL Developer, ApEx and sundry other tools, offering some insights into his various projects. This is the sort of thing that justifies these conferences. Mike is the guy who wrote the first version of HTMLDB, having been the guy who wrote its predecessor, WebDB. So it was great to hear what he has to say about his thought processes as he started the development of HTMLDB.

The original model for HTMLDB was the ATM - a page flow with validation and decision points. From the beginning Mike wanted the tool to be declarative for ease of coding and consistency of execution. This also promotes modularity. He also wanted it to be more flexible than Forms, which is great for building standard apps but gets very truculent when we want to go off-piste. Another important decision was that HTMLDB would build metadata driven applications rather than being a code generator. This makes it much more interactive. During the earlier days of development Mike was working in the same room as Tom Kyte. So he had instant access to AskTom, as a result of which ApEx is highly optimised for assembling apps on the fly.

Also Mike and his team are committed to building a community around ApEx as a tool. For instance, they actively participate in the forums. They are also looking to build up a library of packaged applications which can be downloaded from SourceForge and installed for free.

The next major release of ApEx is like to feature Flash widgets for generating charts, integration with XML Publisher and an AJAX-driven WYSIWYG form layout editor.
Version control still seems somewhat clunky, requiring as it does several manual steps to get the application out of the workspace and into the source control repository. I think this is a barrier to its acceptance as an enterprise tool; I will be waiting to see whether the ApEx team manage to take advantage of the 11g (BETA!) object versioning feature.

The second session I attended was Cecil Hamilton-Jones talking on The Search For A Generic Data Model: Introducing The Associative Data Model. This was a quest for "life beyond the relational data model" and was always going to be a provocation. Which is fine: we can all benefit from having our assumptions challenged by new ideas. The problem with Cecil's presentation was that it was that was riddled with inaccuracies, confusions and unsubstantiated assertions. He repeatedly blurred the distinction between the relational data model and the process of building applications. He alleged that every time we start a new project we build a new set of tables. He also said that existing RDBMS products were not fit for the Internet business model; this will be news to Google, Amazon and all those other outfits limping along. As for his statement that the relational model was "a perfect fit for SQL", well, it was a shame Hugh Darwen was not present.

The associative data model itself is an interesting theory. It builds on concepts from social science - triple stores, semantic networks and other interesting stuff - to organise data. Everything is either an entity or an association. Associations specify the links between entities. The resulting patterns of data are built up like sentences: subject verb object. This is recursive, so that a subject can itself be built up of prior triple stores. However, as Noam Chomsky once pointed out, it is perfectly possible to write sentences which are syntactically correct but meaningless. Without relational integrity and candidate keys how does the ADM ensure meaning? Apparently it is handled by the application. Hmmm.... Of course the real reason why similar key-value pair solutions have failed in the past is that they fail to scale. Cecil interpreted this question as a matter of number of users but the problem is one of querying large tables with no meaningful indexing.

I'm trying not make this seem like a hatchet job but it's difficult. I'm totally in favour of the UKOUG offering presentations which fall outside the realm of Oracle technology and applications. I think they provide interesting perspectives on the main topic. But the standard of proof for theoretical papers needs to be as high as that for practical papers on query optimisation and the like.

No comments: