5 ms·
Some RDBMS features, such as stored procedures and views, can quite naturally be versioned, and become as ephemeral as your application code. For example, have
by oftenwrong 3y ago
Some RDBMS features, such as stored procedures and views, can quite naturally be versioned, and become as ephemeral as your application code.
For example, have your application setup a schema to contain its version-specific database components. The schema will contain an immutable application version, such as its commit hash, in its name. This allows a given version of the application to only use its own set of sprocs and views. On deploy, run the SQL scripts to create the sprocs and views for that version.
You'll note that sprocs and views are not mutated under this strategy. This allows multiple versions to exist concurrently, which facilitates things like blue-green deploys.
- gonzo41 3y agoWhat you're describing can be done to great success with the right type of requirements. Say you're building an information warehouse for OLAP style work. Totally makes sens to pyt all the heavy stuff in the DB because the data model is going to be pretty rigid and it's the sort of asset to get enough attention from the business to be supported correctly with a full staff. On the other hand, defnining everything in code and using the db as a dumb store that's fractionally better than using files is a pretty good strategy when you may be handing over support to a team that won't be giving full time attention to the app. It also handles those key person risks etc by keeping thigns in one area of the app code.
- Spivak 3y agoI've only ever seen this work with "application managed databases" i.e. where the app truly owns and controls everything related to the database and can freely run ddl. The db code is then just part of the app and can be spun up against a completely empty db. The death for this kind of thing is dbas administering the database separately because the coupling will kill you.