Databases are APIs
I recently realized something: databases are APIs.
Just like library functions and classes with defined methods, the columns and tables and inter-table relationships in your databases are effectively a collective API to the database. (As distinct from the APIs used to talk to the database program, ranging through ODBC to SQL.)
If you have what Martin Fowler calls an application database, used only inside one application, you have an internal API, just like a module's interface or a class's methods. But if you have an integration database, a database that integrates data across multiple applications, then your database is a public API.
I find this a useful insight because it gives me a different and much more accessible perspective on a number of database design issues. For example, no wonder DBAs twitch when people propose changing the schema in a public database; you're proposing a change to a public API, with all that that implies.
One of the problems of databases as APIs is that the API is amazingly low level and direct; it's the rough equivalent of directly reading and writing member variables in objects. This creates serious limitations in supporting backwards compatibility if we evolve the database 'API' by changing tables, columns, and interrelationships (as shown in yesterday's example of a problem in an evolving database).
(This makes the DBA love of stored procedures, the 'level 2' approach from my 'Three levels of database usage' entry, make much more sense. Backwards compatibility is much easier with them.)
The other problem for refactoring databases, even application databases, is that they are not just an API. Databases are also the stored data, so you can't just evolve the API itself; you need to also evolve the stored data so that it means the same thing as it used to.
One way to do this is to provide a tool that exports the data with its meanings exposed, and another tool that loads meaning-exposed data into the database. (This is one of the cases where I think XML makes a lot of sense; it's relatively easy to express meaning explicitly, and there are well developed XML generators and parsers. This also casts an interesting light on the desire of people for 'XML databases'.)