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

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 facilitar a escrita de consultas para os analistas de negócios. Estamos usando o Django e seu ORM.

Em um caso, mantemos um objeto MedicalRecordNumber com uma string exclusiva que identifica um paciente em um determinado contexto. Temos objetos de registro que rastreiam pacientes e associaram MedicalRecordNumbers , mas, em vez de usar um relacionamento de chave estrangeira, eles duplicam a string para evitar a gravação de uma junçã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 tempo limitado de processamento cognitivo. É um problema sistemático. Não se sentir à vontade para escrever junções é uma questão de habilidades retificáveis. Eu não quero necessariamente advogar voltar e alterar o esquema, mas adoraria poder articular de forma convincente os problemas com esse tipo de duplicação.

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

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

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

Se você disser aos analistas / gerentes de negócios seniores que fazem muitas associações para uma análise simples, bem, você poderá ser demitido.

O Agile Data Warehouse Design é um bom livro

Veja minhas dicas rápidas e sujas sobre data warehouse aqui

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

Mas você pode criar uma visualização uma vez 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.

As respostas que já foram votadas abrangem praticamente o "como evitar a duplicação" (usando visualizações), mas não o porquê. Eles basicamente mostram que a duplicação de colunas é a solução errada para o problema de facilitar a gravação de consultas. Mas a pergunta "por que não duplicar qualquer coluna aleatória apenas para o inferno?" Ainda está de pé.

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

Se algo pode dar errado, vai dar.

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 possíveis para garantir que elas não sejam diferentes, mas a lei de Murphy declara que, uma vez que podem ser diferentes, elas serão diferentes. E haverá destruição .

Como um exemplo de como isso pode acontecer, basta considerar o fato de que as colunas duplicadas não são preenchidas por mágica; alguém deve realmente escrever um código que armazene valores neles sempre que as linhas são criadas na tabela original e alguém deve escrever um código que continue atualizando-os sempre que os originais forem modificados. Deixando de lado o fato de que isso está adicionando uma carga indevida ao 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 se lembrar de realizar a duplicação, mas não dentro de uma transação, de modo que, sob certas condições raras de falha, seja omitida. Mas eu realmente não precisava perder meu tempo escrevendo esses exemplos,se pode dar errado, vai dar.

Pensar nisso em termos de troca, em vez de bom / ruim, será mais produtivo. Eles estão trocando 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 severamente 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.
• Encaminhe o acesso de gravação por meio de software que atualize os dados replicados de forma consistente.
• Adicione visualizações ou construa ferramentas de consulta que fazem as junções automaticamente, para que os empresários possam pensar em termos de informações, e não nos dados internos do banco de dados.

Eu acho que o argumento mais forte para normalização de dados para analistas de negócios é que ele promove a integridade dos dados. Se seus dados principais estiverem armazenados em apenas um 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, portanto essa pode ser uma boa maneira de convencê-los a atualizar suas maneiras de interagir com o banco de dados.

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

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

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

Sair.

Honestamente, você pode passar meses discutindo sobre normalização, consistência e combatendo bugs malucos causados ​​por pura preguiça e depois sair.

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

Bons programadores são pessoas muito preguiçosas. Eles entendem as necessidades dos clientes e da gerência. Mas o mais importante é que eles entendem que resolver bem os problemas, usar soluções bem projetadas e bem implementadas, os poupa pessoalmente GRANDES quantidades de trabalho, esforço e, principalmente, agonia e estresse.

Então você seria muito melhor trabalhando em um lugar que entenda e valorize a boa engenharia.

Boa sorte.

Pensamento Posterior: Talvez o que eles precisem sejam ferramentas de BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing