Controlador de versão SQL

Normalmente faço commit dos scripts ligados a um chamado que gerou a alteração.
Como trabalhamos com o conceito de Service Desk, tudo gera um chamado, que gera um script de alteração, que é versionado.

Tudo depende do contexto, e fazer commit a cada alteração é válido.

Lembre-se que tem 2 backup´s tem 1.

Ser prudente não faz mal a ninguém.

Ei Glauco, acho que não entendi muito bem sua pergunta, está querendo dizer de Auditorias?
Geralmente cria-se uma tabela de LOG para registro de ações realizadas por usuários (Insert/Update/Delete)

Espero que tenha ajudado,

Abraço !

Só completando a resposta da Stella Oliveira, a pergunta não esta clara ser for log ou trilha de auditoria o caminho é o indicado pela Stella.
E você pode utilizar triggers para facilitar sua vida.

Agora se for alterações estruturais, seria necessário ser mais claro e nos dar mais informações de seu ambiente.

Pessoal a pergunta está relacionada ao controle de mudanças no banco de dados, para código usamos muito GIT, hoje eu incluo no commit a cada alteração de tabela, etc.
Vocês também fazem desta forma ?

No caso se você está dizendo em versionar ações realizadas no banco (pelo usuário), se trata de auditoria mesmo.
Agora se são ações realizadas por desenvolvedores (versionamento) eu geralmente faço controle por uma tabela de log, cada ação do desenvolvedor só é permitida (em produção) depois de uma requisição liberada para o ID do mesmo.

Onde eu trabalho,também é desta forma. Fico pensando na possibilidade de utilizar o migrations do netcore

Seria um pensamento de desenvolvedor.

Em bancos de produção os backups tem um periodicidade o que mantém a estrutura atualizada.

Normalmente em ambiente de homologação os backups são esparsos e como normalmente é um ambiente "sem dono", a probabilidade de dar merda é grande.
Normalmente faço um backup ou gero um script da estrutura do banco de dados e versiono.

Como o BD não sofre tanta modificações assim, acaba que não temo muitas versões.

Migrations é uma mão na roda, uso no Ruby e no .Net e facilita a vida, agora a equipe tem de estar ciente de como usar para evita problemas.

Quais problema, poderiam ocorre que vocÊ tem ciência?

Talvez eu tenha me expressado mal, o correto nem seria problemas, mas mau uso.

Em equipes pequenas é mais fácil disseminar o rito de manter tudo sempre atualizado e sempre buscar a última versão do que vai ser alterado, antes de efetuar qualquer mudança. E sempre efetuar os commits ou no caso das migrations o UpdateDataBase.
Em equipes grandes ou fábricas de software pode acontecer de algum meliante pular alguma etapa e gerar conflitos, por não ter seguido os passo acima. Ou mesmo excluir alguma migration na mão seja no BD ou no projeto da aplicação. E isto pode gerar vários transtornos, principalmente no ambiente de produção. Pois em algumas empresas a publicação em produção é bem burocrática ou mesmo limitada por processos quase ritualísticos.

No final é mais uma sintonia final no time e todos compreenderem que os processos devem ser seguidos.

Claro que tudo que foi exposto acima é contornável com o versionamento e restore de backup. Contudo, por experiência própria restaurar um backup dependendo do contexto é osso.

Só mais uma coisa o time tem de ficar experto com cascade delete, pois se usado de forma equivocada pode fazer um limpa nos dados indevidamente.

Como eu já disse seja prudente e faça backups de tudo, pois é mais fácil limpar backups inúteis que não tê-los em caso de necessidade.