Como posso argumentar convincentemente contra a duplicação de colunas do banco de dados?

47

Comecei a trabalhar em uma nova organização e um dos padrões que tenho visto no banco de dados é a duplicação de campos para tornar as consultas por escrito mais fáceis para os analistas de negócios. Estamos usando o Django e seu ORM.

Em um caso, mantemos um objeto MedicalRecordNumber com uma string exclusiva identificando um paciente em um determinado contexto. Temos objetos Registration que rastreiam pacientes e associam MedicalRecordNumbers , mas em vez de usar um relacionamento de chave estrangeira, eles duplicam a string para evitar escrever uma união ( não por motivos de desempenho). Esse padrão é comum em todo o banco de dados.

Para mim, a importância de um modelo de dados estar limpo é apenas para que eu possa pensar bem. A complexidade desnecessária é um desperdício do meu limitado tempo de processamento cognitivo. É um problema sistemático. Não se sentir confortável em escrever joins é um problema de habilidades retificável. Eu não quero necessariamente advogar voltar atrás e mudar o esquema, mas eu adoraria ser capaz de articular de forma convincente os problemas com este tipo de duplicação.

    
por canisrufus 11.04.2015 / 18:44
fonte

7 respostas

129

Seu banco de dados operacional deve ser altamente normalizado para reduzir anomalias .

Seu banco de dados analítico (warehouse) deve ser altamente desnormalizado, para facilitar a análise.

Se você não tiver um banco de dados analítico separado, faça algumas visualizações [materializadas] altamente desnormalizadas.

Se você disser aos seus analistas / gerentes de negócios seniores para fazer várias associações para uma análise simples, você pode ser demitido.

Design ágil de data warehouse é um bom livro

Veja minhas dicas de armazenamento de dados sujas e rápidas aqui

    
por 11.04.2015 / 22:22
fonte
57

Eu entendo por que alguém quer evitar escrever uma associação para cada seleção.

Mas você pode criar uma vez uma visualização com a associação e usá-la em vez de sua tabela não normalizada.

Assim, você combina a vantagem da normalização com a conveniência de uma seleção fácil.

    
por 11.04.2015 / 20:17
fonte
13

As respostas que já foram upvoted cobrem o "como evitar duplicação" (usando views), mas não o porquê. Eles basicamente mostram que a duplicação de colunas é a solução errada para o problema de tornar mais fácil escrever consultas. Mas a pergunta "por que não duplicar qualquer coluna aleatória apenas para o inferno dele?" Ainda está de pé.

A resposta é "Por causa da Lei de Murphy". A lei de Murphy afirma que:

If something can go wrong, it will.

Nesse caso, o conteúdo de cada campo de linha de uma coluna duplicada deve ser idêntico ao conteúdo de cada campo de linha correspondente da coluna original. O que pode dar errado, é que o conteúdo de alguns campos de linha pode diferir dos originais, causando estragos. Você pode pensar que tomou todas as precauções concebíveis para garantir que elas não sejam diferentes, mas a lei de Murphy afirma que, como elas podem diferir, elas serão diferentes. E havoc será seguido.

Como exemplo de como isso pode acontecer, simplesmente considere o fato de que as colunas duplicadas não são preenchidas por mágica; alguém deve realmente escrever código que armazena valores neles sempre que as linhas são criadas na tabela original, e alguém deve escrever um código que continue atualizando-as sempre que os originais forem modificados. Deixando de lado o fato de que isso está sobrecarregando indevidamente o código que insere dados no banco de dados (e que é, por definição, muito mais crucial do que qualquer código que simplesmente consulta o banco de dados), alguém, em algum lugar, sob certas circunstâncias, pode esquecer para realizar essa duplicação. Então, os valores serão diferentes. Ou eles podem lembrar-se de realizar a duplicação, mas não dentro de uma transação, para que ela possa, sob certas condições de falha raras, ser omitida. Mas eu realmente não precisava perder meu tempo escrevendo esses exemplos, e você realmente não precisava desperdiçar seu tempo lendo-os: a beleza da Lei de Murphy é que ela nos poupa de ter que dar exemplos de como algo pode dar errado. caso a caso: se puder dar errado, será.

    
por 12.04.2015 / 11:52
fonte
12

Pensar nisso em termos de compensações em vez de bom / ruim será mais produtivo. Eles estão trocando as vantagens da normalização (especialmente consistência) por vantagens na usabilidade da consulta.

Em um extremo, o banco de dados se tornaria inútil se os dados ficassem gravemente inconsistentes. No outro extremo, o banco de dados seria inútil se for muito difícil para as pessoas que precisam consultá-lo todos os dias para obter resultados com os quais possam contar.

O que você pode fazer para reduzir os riscos e os custos?

  • Crie uma ferramenta de verificação de consistência e execute-a regularmente.
  • Roteie o acesso de gravação por meio de um software que atualiza os dados replicados de forma consistente.
  • Adicione exibições ou crie ferramentas de consulta que façam as associações automaticamente para que as pessoas de negócios possam pensar em termos das informações, em vez das internas do DB.
por 11.04.2015 / 22:20
fonte
6

Acho que o argumento mais strong para a normalização de dados para analistas de negócios é que ele promove a integridade dos dados. Se os dados da chave estiverem armazenados em um único local (uma coluna, em uma tabela), é muito menos provável que os dados sejam corrompidos por atualizações incorretas. Eu acho que eles provavelmente se importariam com a importância da integridade dos dados, então isso pode ser uma boa maneira de convencê-los a atualizar suas formas de interagir com o banco de dados.

Um método um pouco mais difícil de consultar provavelmente será preferível à possível corrupção de dados.

    
por 11.04.2015 / 19:22
fonte
0

Para adicionar o que os outros caras sugeriram acima. Este é um problema de governança de dados. Você precisa trabalhar com partes interessadas relevantes: arquitetos de dados e administradores de dados para desenvolver princípios de dados, políticas e convenções de nomenclatura.

Seja paciente e trabalhe metodicamente. A mudança não acontecerá durante a noite.

    
por 17.04.2015 / 08:45
fonte
0

Sair

Honestamente, você pode passar meses discutindo sobre normalização, consistência e combater insetos malucos causados por pura preguiça, e então desistir.

Ou você pode economizar tempo e frustração e sair agora.

Bons programadores são pessoas muito preguiçosas. Eles entendem as necessidades de clientes e gerenciamento. Mas o mais importante é que eles entendem que resolver problemas bem, usar soluções bem projetadas e bem implementadas os salvam de quantidades ENORMES de trabalho, esforço e, o mais importante, agonia e estresse.

Assim, seria muito melhor trabalhar em um local que entende e valoriza a boa engenharia.

Boa sorte.

Considerações finais: Talvez o que eles precisem sejam ferramentas BI / OLAP ... link

    
por 17.04.2015 / 16:43
fonte