What he's imagining is somewhat close to what we do with our currently-internal (hopefully open source some day) ORM framework (which is on Java). Our schema i

What he's imagining is somewhat close to what we do with our currently-internal (hopefully open source some day) ORM framework (which is on Java). Our schema is defined as metadata in XML, and we build a checksum off the XML to compare against what's in the database in order to know when to upgrade. To ensure the stability of the checksum, it's built off of a filtered, sorted version of the XML DOM tree, rather than the actual files. Not all changes to the files will affect the checksum, since certain bits of the metadata don't affect the data or the schema. We do still use explicit version numbering for version triggers (our name for migrations), since it's just too hard if the numbers aren't meaningful. If you just used a checksum, how would you know if A248B5FC comes before or after 3F56EB2? It's a little easier if you can say "the DB is at version 23, and the latest is version 26, so we need to run these three triggers." The database stores both the metadata checksum as a hash and a version number; if the hash changes without the version number changing, we at least know that's an error and can detect it. Certain types of changes (like adding a nullable column) we handle automatically by diffing the current schema against the actual DB schema, while anything more complicated (and anything that touches the data) requires an explicit trigger. Since we build deployed enterprise software that gets upgraded on the scale of years, not days or weeks, we also follow the course of using triggers only on production databases. It's still not really a perfect solution for all sorts of reasons I could go into, but it's interesting that we ended up pretty close to what he's proposing.