Harry Pierson blogged about The Dual Schema Problem the other day as being a big problem when developing apps. Dual as in one "schema" for the domain model (at least that's how I read his post) and one schema for the database.
I agree, it's troublesome, and is a problem that I think is worth trying to do something about. Here are some reflections.
- Nowadays I most often try to focus on the domain model (schema) when I'm developing. I regenerate the database schema for the relational database automatically from what the domain model looks like. This is nothing fancy and is probably the norm for lots of projects. Then I optimize what has to be optimized, but I don't start the other way around. Again, this won't be suitable for every project...
- Harry talks about letting go of the relational database, and seeing the domain model as the database with an open source project called Consus. Another such project that I think has been talked about quite a lot is Prevayler. However, according to Harry, a big difference is that for Consus, tables are built in runtime. With Prevayler, what is stored in the log is the commands.
- Oh, and my pet project NWorkspace is pretty much about avoiding that dual schema problem, at least during early development. You can start building the whole thing without a relational database, persisting an image of your domain model instantiation so that the user can try out your app without a database. No need to synch with a database schema at all. Later on in the project, you instantiate another NWorkspace-implementation, letting it talk with the database instead. Again, nothing fancy, but an attempt to reduce the problem Harry is talking about.
Before the flames start, let me just point out that I don't see the above as a way of abstracting away the database. I think it's extremely important to know about databases and be prepared to deal with them more on the low level when really needed.