I am not sure if what I’m asking is even possible (or desirable, for that matter), but we were wondering what would be the best way to handle SQL changes to a Database schema, when this schema is shared across multiple apps/teams.
We work for a large corporation where database schemas are shared between different software applications (and therefore independent, unrelated, incommunicated, development teams). This means that certain changes to the schema (new views, procedures, constraints, tables, etc.) can come from a variety of apps.
Having version control of the DB objects is ideal, but depending on the strategy
- either a DB snapshot has to be composed from the changes produced by different apps (who knows which?), by traversing all possible apps that touch that schema,
- or to see the latest changes in a specific application’s version, two (or more) repositories have to be checked (in addition, there is no hard-link between
commits
,releases
, etc.).
i.e: Attempting to version control the schema objects (Oracle) puts us in the dilemma of how to do so:
- Do we store the changes to the different schema objects inside the application’s repository (thus distributing the schema snapshot between an undefined nº of repos)?
- Or do we have separate repositories for the DB schemas, and make two (or more)
commits
to different repositories when a new version is uploaded (thus difficulting the compilation of a newrelease
changeset)?
I was wondering if it was possible to specify in Git:
Whenever you make a push
on the Application
repo, send the files in the /SchemaA SQL/
folder to SchemaA
repository, the files in /Schema B/
folder to the Schema B
repository, and finally the rest to the Application
repository. Thus, distributing the contents of the commit
between repos in a single operation. Maybe .gitattributes
? If using Github/Gitlab, maybe through a webhook on the remote?