You Can’t Import Usability
There is a spectrum of choices between a traditional spreadsheet and a traditional database. Perhaps a more usable system in this space would allow someone to begin working more like a spreadsheet and allow shapes to emerge and be supported more like a database, but not expose that support in traditional database terms.
One crude way in which this happens already is for database systems to support spreadsheet imports, creating and populating a database table based on the structure and data of an Excel file. The idea here is that you can get started on your application in the familiar, free-form environment of a spreadsheet, where it’s easy to add new columns and enter data. Then, when you’re ready to “move up” to a database, just do a simple import and away you go.
Clearly, this is a useful and essential feature for legacy data stored in old spreadsheets: any database product that didn’t provide some way to bring in that information would be sunk. What’s deceptively appealing, however, is the idea that this is also a good way to build new applications. QuickBase, for example, recently added a feature called Spreadsheet-Style Create. It’s a good start, but the focus on creation bothers me. If everyone knew from the start exactly what their app would look like, then this would work great, but real life doesn’t work that way: there are always going to be fields to add, remove, split, merge, and migrate; new batches of data to enter; new relationships to other pieces of data that you never knew you cared about. The problem with imports and special create modes is that they’re a one-time offer: once you take it, you’ve shut the door on the spreadsheet’s ease of use, and are stuck with the database’s standard modelling tools. Almost by definition, they will be harder to use than the spreadsheet was - or what would have been the point of starting things that way in the first place?
Personally, I would rather that the database system made it easy enough to build my application from scratch that I didn’t feel a need to use the spreadsheet as a crutch. That’s the only way I’ll know that if I need to make significant changes later, they will be just as easy as the initial setup was. Maybe that means taking a cue from QuickBase, and providing two kinds of tool: one aimed at rough field creation and bulk data entry, and another aimed at smaller, more detailed refinements. But make both sets of tools available at all times, operating on the same data model, rather than locking one of them to the beginning of the application’s lifecycle.