Quais são as melhores práticas para desativar colunas obsoletas do banco de dados? [fechadas]

Estou projetando um aplicativo que, em um estágio inicial, coletará os dados A, B e C dos clientes, mas posteriormente coletará os dados A, B e D.

A, B, C e D estão muito relacionados e agora existem como colunas de uma única tabela T do PostgreSQL de banco de dados .

Uma vez que C não é mais necessário, desejo remover suas referências do meu aplicativo (uso o Django ORM ), mas quero manter os dados que já foram inseridos. Qual é a melhor forma de fazê-lo?

Eu pensei em criar uma nova tabela para ABD, mas isso significa que pode causar problemas com qualquer linha de referência à tabela T.

Eu poderia simplesmente deixar a coluna C junto e remover referências a ela no código, permitindo que os dados existentes sobrevivessem.

Existe uma opção melhor que não estou vendo?

Alguns detalhes extras:

O número de linhas não será grande, provavelmente 1-2 por usuário. Esta é uma aplicação de mercado de massa, mas quando eu mudar de C para D, a base de usuários ainda não será muito grande. C e D provavelmente não serão coletados ao mesmo tempo, embora essa seja uma possibilidade. C e D provavelmente representam várias colunas cada, e não apenas uma cada.

Se você deseja manter os dados, não é obsoleto. Apenas deixe onde está. Tudo bem se alguma classe mapeada para uma tabela não mapear todas as colunas.

OK, então sua situação é que você deseja que as linhas antigas tenham a propriedade C, mas as novas não.

Isso é equivalente a ter um relacionamento de herança de classe

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

que você representaria no banco de dados com três tabelas com relações 1 a 1

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

Assim, você pode criar um script de migração para criar a nova tabela Antiga, copiar os dados de ID e C para ela e remover a coluna C da tabela Todas.

Atualizando seu código conforme necessário com o novo sql;

Como alternativa, se você apenas precisar consultar os dados C antigos, poderá criar uma nova tabela de arquivamento com A, B, C copiar todos os dados e remover a coluna C, adicione o Dcol à sua tabela 'Ao vivo'

Se o armazenamento de dados for uma preocupação, divida as tabelas: tecla / tecla A / B / tecla C / D

Você pode executar o acesso por meio de uma visualização (definição do local dos dados no banco de dados) ou alterando a definição do ORM.

Esse não é o melhor desempenho (uma associação está envolvida), mas pode apresentar qualquer combinação de A / B / C / D ao longo do tempo sem alterar o armazenamento subjacente e, dependendo dos padrões de acesso reais, pode ser suficiente.

Você pode não ter sorte com a capacidade de reduzir o tempo de inatividade, reestruturar tabelas etc. em um sistema de produção.

A realização do acesso através da visualização permite alternar de A / B / C para A / B / C / D para A / B / D na tabela subjacente com alterações mínimas e sem movimentação de dados. Uma visualização será transparente para a lógica de leitura e, se o seu dbms suportar funções ou visualizações atualizáveis, também será transparente para a lógica de gravação.

Realmente acho que sua decisão refletirá muitas preocupações do mundo real: 1) quais são os tipos de dados C & D 2) os volumes de dados relativos coletados para C / D 3) Sobreposição relativa de dados de C / D em comparação com entradas puramente de C ou D 4) Disponibilidade e duração da janela de tempo de inatividade / manutenção 5) Suporte ao DBMS para visualizações atualizáveis ​​6) Desejabilidade de manter os detalhes da estrutura física do banco de dados no ORM versus torná-lo transparente, apresentando-se através de visualizações / funções no banco de dados (onde é o mesmo para todos os acessadores) aplicativos, não apenas o atual)

Minha resposta preferiu tipos de dados grandes / complexos para (1), pouca sobreposição para (3) e tempo de inatividade mínimo para (4), idealmente com bom suporte a dbms em (5) e vários aplicativos acessando os dados em (6)

Mas não há certo / errado para muitas alternativas S: - comece com A / B / C, depois adicione D, ajuste ORM, ainda mais tarde solte a coluna C - comece com A / B / C / D e ignore valores nulos etc. , considere sua solução e o que você sabe sobre o objetivo / ciclo de vida pretendido, faça alguma modelagem de tamanho / volume e espere mudar as coisas mais tarde, pois nem tudo ficará como esperado.

Remover referências e tornar os dados órfãos é uma opção de baixo risco.

Sempre há possíveis usos desconhecidos dos dados 'backdoor' que podem ou não ser importantes para expor removendo a coluna.

Dependendo do conteúdo da coluna C, pode haver um pequeno problema de desempenho quando o banco de dados realiza varreduras completas da tabela internamente ou tenta colocar a tabela inteira na memória durante as junções, se o otimizador considerar isso mais eficiente do que usar índices.

Os aplicativos podem estar lendo a tabela inteira algumas vezes, e não as colunas selecionadas - mas se você estiver usando um ORM exclusivamente, isso é improvável.

Muitas coisas a considerar aqui, mas você pode considerar adicionar uma exibição para sobrepor a tabela em vez de fazer alterações diretamente na tabela. Dessa forma, é apenas a visão que precisa mudar.

Não conheço o Django ORM, mas poderia ser uma possibilidade.

• Você tem uma tabela A com as colunas a, b, c.
• Crie uma nova tabela B com as colunas a, b, d.
• Migrar seus dados para a Tabela B.
• Mova suas chaves estrangeiras para a tabela A para a tabela B.

Agora você pode usar a Tabela B e ainda terá seus dados antigos para referência.