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
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)
commitsto different repositories when a new version is uploaded (thus difficulting the compilation of a new
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?