Excluindo uma coluna de uma tabela na produção

Temos uma situação em que precisamos alterar o relacionamento entre 2 tabelas de m: 1 para m: n .

Portanto, precisamos criar uma tabela de referência cruzada entre essas duas tabelas.

Depois de migrar todos os dados existentes da tabela "filho" para a tabela de referência cruzada, seria uma má idéia excluir a coluna de chave estrangeira original na tabela filho?

Se deixarmos lá, temos basicamente dívidas técnicas. Mas eu não sou um dba e não tenho uma boa compreensão das implicações de excluir uma coluna de uma tabela. (Eu sei que é possível, mas é uma má idéia? Meu banco de dados vai me odiar por isso?)

obrigado

Sem conhecer toda a estrutura de suas tabelas, sou limitado em meus conselhos. No entanto, não, seu banco de dados não plotará sua morte se você remover uma coluna nas seguintes circunstâncias (de maneira alguma exaustivas):

1. Você ainda usa uma chave de banco de dados para mapear suas dimensões.
2. Seus novos índices nesta nova tabela de dimensões estão cobrindo adequadamente os índices quando deveriam.
3. Você administra esse número de índices para não sobrecarregar Inserções / Atualizações

Seu novo design possui duas tabelas de dimensão e uma tabela de fatos

• É por isso que passou de m: 1 para m: n com uma tabela de "referência cruzada". Chamamos isso de outra dimensão.

O design realmente implementou a Normalização para conseguir isso

• Ao remover uma dependência, sua equipe estará melhor equipada para recuperar fatos que podem transformar a maneira como seus dados são processados ​​de uma maneira mais significativa.

Nota sobre dimensões e fatos

• Dimensões para o contexto descritivo

As dimensões fornecem o contexto "quem, o que, onde, quando, por que e como" em torno de um evento de processo de negócios. As tabelas de dimensões contêm os atributos descritivos usados ​​pelos aplicativos de BI para filtrar e agrupar os fatos. Com o detalhamento de uma tabela de fatos em mente, todas as dimensões possíveis podem ser identificadas.

Sempre que possível, uma dimensão deve ter um valor único quando associada a uma determinada linha de fatos . Às vezes, as tabelas de dimensão são chamadas de “alma” do data warehouse porque contêm os pontos de entrada e rótulos descritivos que permitem que o sistema DW / BI seja aproveitado para análise de negócios. Uma quantidade desproporcional de esforço é colocada no controle de dados e no desenvolvimento de tabelas de dimensões, porque eles são os fatores determinantes da experiência de BI do usuário.

• Fatos para medições

Os fatos são as medidas que resultam de um evento do processo de negócios e são quase sempre numéricos. Uma única linha da tabela de fatos possui um relacionamento individual com um evento de medição, conforme descrito pelos grãos da tabela de fatos . Assim, uma tabela de fatos corresponde a um evento físico observável, e não às demandas de um relatório específico . Dentro de uma tabela de fatos , apenas fatos consistentes com o grão declarado são permitidos . Por exemplo, em uma transação de vendas no varejo, a quantidade de um produto vendido e seu preço estendido são bons fatos, enquanto o salário do gerente da loja não é permitido.

Técnicas de modelagem dimensional de Kimball

Minha sugestão é que a equipe de design deva saber que aplicar as regras no banco de dados é melhor, a menos que prejudique o desempenho. Eu não sei o tamanho ou quantificação de suas instruções DDL para responder completamente a isso, no entanto.

Mas tenha certeza de que isso deve ser uma alteração positiva em seu sistema, pois agora o SQL Server não precisará passar por todos esses dados extras para recuperar o que realmente importava.

Eu sei que é possível, mas é uma má ideia? Meu banco de dados vai me odiar por isso?

Não posso falar pelo seu banco de dados, mas odiaria você por isso :-)

A coluna herdada conterá dados redundantes após a alteração. Isso pode resultar em dados conflitantes se a coluna antiga e a nova tabela de refex não forem mantidas consistentemente entre si. Considere que desenvolvedores que não estão familiarizados com a dívida técnica podem corromper logicamente o banco de dados.

Tenho dificuldade em pensar em uma razão pela qual não se deve remover a coluna e o relacionamento herdados. Isso também garantirá que todo o código dependente seja alterado corretamente.