Fire Trucks and Databases

The Hawaii state fire department is having trouble figuring out how to automate their building inspection database. They have now spent a half million dollars on contractors for two failed systems in a row, and so far the most promising solution is an internally-developed hack job that at least tracks the right information, even if it's not centralized.

I've got this funny feeling there's a market for turn-key centralized database systems which develop as if they were MS Access or something. The trade-off I see with big-iron databases is that you have to create your interfaces from first principles: C++ or PHP or the like.

PC database systems were a big hit largely because they made forms-based applications simple. Nobody wants to type a bunch of SQL to manage their vinyl album collection or recipe book. Instead, you created your database and its CRUD screens in a simple interface.

There are now plenty of frameworks (such as RAILS) that take care of lots of the work involved in delivering database applications on the web. However, they still require command-line voodoo to operate, and they still are only as safe as the guy writing the code underneath. They can't make your schema for you, and most times they won't even try to help with that part. Instead, you get to use some other tool to construct the underlying database, and then wrap that with the interface builder of choice.

The paradigm was right twenty years ago. Database systems should be developed at the level of use. If you need a list of checkboxes, then that's what you need. It should be the development tool's responsibility to turn that requirement into a database schema, and also to generate and manage suitable query screens that stay correct and operational regardless of what happens to the schema.

To make this work, the development tool needs to understand the semantic connections between different features and facets of the end user system. A really smart group of people would have to study successful database-driven applications to figure out what really binds such tools together. Then, they would have to wrap that whole bundle of knowledge into an automatic intelligent tool.

The real value, though, is in the uber-tool that automates the creation of intelligent development tools such as the one described above.