I looked at the Houston project CTP for SQL Azure with a low whistle of dismay. I'd been expecting, and hoping for, something else. A proof-of-concept tool such as Houston would, I thought, produce a radical step forward in enabling data, application and enterprise architects to capture the data model, and then represent and share it, so it can be quickly built on SQL Azure. Instead, we seem to have the ideal tool for building a database of your CD collection.

"... designed specifically for Web developers and other technology professionals seeking a straightforward solution to quickly develop, deploy, and manage their data-driven applications..."

In other words, this is for the amateurs only.

After the disappointment of Oslo aka SQL Server Modelling CTP, I'd built hopes on Microsoft coming up with a tool that was fit for creating solid commercial-scale database applications in the 'cloud'. We've been told that an army of Microsoft 'suits' have spent a year or so interviewing DBAs, in order to define a new generation of tools that will revolutionise the way we construct database applications.

Did these conversations really go something like this...

Suit: (looking earnest and attentive): How can we improve the tool you use to build stored procedures?

DBA:  Hmm. That button needs to be shiner, slightly more 3-D. SSMS was boring, so...err...white. (Suit scribbles notes) We need something cool. What about an industrial charcoal metallic background with a contemporary laser-light swishy pattern.

Suit: It doesn't have to do any more, does it? Just allow you to edit a table, build views and do stored procedures?

DBA: (shrugs vaguely) Hmm. That's about all there is to a Cloud application, surely?'

No. it doesn't ring true. There is more to a database tool than this. A tool for professional database developers must start by allowing them to define the context of the application within the enterprise; to help them understand and represent the architecture of the data and the issues of how the data is used within the enterprise. Then it should support them through the struggle of understanding the language of data and processes within the domain of the application, and communicating that understanding to the developers.

With all this architectural spadework in place, it becomes easy to create a normalised model, complete with constraints, defaults, and special data types. A database tool for this sort of work must inevitably be intensely graphical, with a serious assimilation and understanding of the knowledge and practice embodied by UML and CSC catalyst.

So why do so many design initiatives for Database Design IDEs from Microsoft miss the key point? With some notable exceptions, few database tools have evolved by finding out how database designers actually work. Microsoft suffers badly from their cultural past with databases, where their own database products, such as Access, have evolved from desktop productivity tools rather than industrial-scale databases. In SQL Server SSMS, diagramming seems to be there 'on sufferance' and hasn't evolved at all from the days of Enterprise Manager, or really from its origin as a component of Access. Sadly, the same problems seem to have beset Houston.

Phil Factor.