I believe you've just described migrations (scripts that modify the schema and run data migrations, checked into source control). Generating the ORM layer from

I believe you've just described migrations (scripts that modify the schema and run data migrations, checked into source control). Generating the ORM layer from the database schema seems OK to me. It does preclude generalizing certain subsets of the schema like e.g. lets say you want to publish a "comments module" reusable across projects that would install its own subset of tables in the DB, as well as provide functions (procedures) to create new tables that link comments to other entities on demand. The problem with relational databases is that SQL has such poor facilities for abstractions. Whereas the typical language today has higher order functions (some even have higher order classes!) stored procedures are quite limited.