What are some strategies for maintaining a common database schema with a team of developers and no D
- by Mahmoud Abdelkader
I'm curious about how others have approached the problem of maintaining and synchronizing database changes across many (10+) developers without a DBA? What I mean, basically, is that if someone wants to make a change to the database, what are some strategies to doing that? (i.e. I've created a 'Car' model and now I want to apply the appropriate DDL to the database, etc..)
We're primarily a Python shop and our ORM is SQLAlchemy. Previously, we had written our models in such a way to create the models using our ORM, but we recently ditched this because:
We couldn't track changes using the ORM
The state of the ORM wasn't in sync with the database (e.g. lots of differences primarily related to indexes and unique constraints)
There was no way to audit database changes unless the developer documented the database change via email to the team.
Our solution to this problem was to basically have a "gatekeeper" individual who checks every change into the database and applies all accepted database changes to an accepted_db_changes.sql file, whereby the developers who need to make any database changes put their requests into a proposed_db_changes.sql file. We check this file in, and, when it's updated, we all apply the change to our personal database on our development machine. We don't create indexes or constraints on the models, they are applied explicitly on the database.
I would like to know what are some strategies to maintain database schemas and if ours is seems reasonable.
Thanks!