Comments posted to this topic are about the item Malleable Source Control
That's a good summary. We tend to hear "migration vs state" model (however less and less). Database development are more like both.
I love SSDT for the state-based approach and script generation. As you mentionned, state-based development has is a lot about the narrative. We get the all picture in one shot. That is kind of lost in a migration only approach.
Also the idea of putting delta (migration) in git feels a bit off. We delta the deltas? Are we accelerating?
... so I drank the state cool-aid as a beginner.
I burned my self by deploying from state n to n+2 in one step. It really is horrible to deal with data changes. Since that, I use it only to generate migration script... no more direct deployment. I should take Flyway or alike to deal with it.
Development feels more state (goal, target) oriented, deployment definitely migration-based.
I never thought about source-controlling data. Isn't that what history logs are for? (I'm a developer, not a DBA, so it's probably not as simple as I'm making it sound.) In cases where a task requires some manual altering of data, I do record the script that I used in our change tracking tool, but I don't bother putting it under source control if it's just a one-and-done.
I've always been satisfied with versioning metadata changes by versioning their DDL scripts. In the case of altering an existing code module, the ALTER script can also serve as the migration script. For table structure changes, though, I prefer versioning the CREATE scripts, not the ALTER migration scripts, because then history comparisons will highlight the changes in their full context.
I never thought about using GIT for this. We don't use that for anything else on our team, so I doubt I can get my co-workers into it, but thanks for provoking that thought.
Viewing 3 posts - 1 through 2 (of 2 total)