tabela fixa única com várias colunas vs tabelas abstratas flexíveis

Resolução de pré-requisito

1. 
   Etiquetas
   Em uma profissão que exige precisão, é importante que usemos rótulos precisos, para evitar confusões e para que possamos nos comunicar sem precisar usar descrições e qualificadores prolixos.
   
   O que você postou como FixedTables é Não normalizado . Justo, pode ser uma tentativa de terceira forma normal, mas na verdade é um arquivo simples, não normalizado (não "desnormalizado). O que você postou como AbstractTables é, para ser preciso, Entity-Attribute-Value , que é quase, mas não exatamente, a sexta forma normal e, portanto, é mais normalizada que a 3NF. Supondo que seja feito corretamente, é claro.
   
   • 
     O arquivo simples não normalizado não é "desnormalizado". Ele está repleto de duplicação (nada foi feito para remover grupos repetidos e colunas duplicadas ou para resolver dependências) e Nulos, é um devorador de desempenho de várias maneiras e impede a simultaneidade.
     
   • 
     Para ser desnormalizado, primeiro ele deve ser normalizado e, em seguida, a normalização recuou um pouco por algum bom motivo. Como não é Normalizado em primeiro lugar, não pode ser Desnormalizado. É simplesmente não normalizado.
     
   • 
     Não se pode dizer que seja desnormalizado "para desempenho", porque sendo um porco de desempenho, é a própria antítese do desempenho. Bem, eles precisam de uma justificativa para a falta de design formalizado], e "para desempenho" é isso. Mesmo o menor escrutínio formal expôs a deturpação (mas pouquíssimas pessoas podem fornecer, então ela permanece oculta, até que alguém de fora resolva, você adivinhou, o enorme problema de desempenho).
     
   • 
     Estruturas normalizadas têm um desempenho muito melhor do que estruturas não normalizadas. Estruturas mais normalizadas (EAV/6NF) funcionam melhor do que estruturas menos normalizadas (3NF/5NF).
     
   • 
     Estou concordando com o impulso dos Pôneis OMG, mas não com seus rótulos e definições
     
   • 
     em vez de dizer 'não "desnormalize" a menos que seja necessário' , estou dizendo, 'Normalize fielmente, ponto final' e 'se houver um problema de desempenho, você não normalizou corretamente' .
     
2. 
   Wikipédia
   As entradas para Formas Normais e Normalização oferecem definições incorretas; confundem as Formas Normais; faltam no processo de Normalização; e dão igual peso a NFs absurdas ou questionáveis ​​que foram desmascaradas há muito tempo. O resultado é que a Wikipedia acrescenta a um assunto já confuso e raramente compreendido. Então não perca seu tempo.
   
   No entanto, para progredir, sem que essa referência constitua um obstáculo, deixe-me dizer isso.
   
   • A definição de 3NF é estável e não mudou.
   • Há muita confusão das NFs entre 3NF e 5NF. A verdade é que esta é uma área que progrediu nos últimos 15 anos; e muitas organizações, acadêmicos e fornecedores com seus produtos com limitações, saltaram para criar um novo "Formulário Normal" para validar suas ofertas. Todos servindo a interesses comerciais e academicamente doentios. A 3NF em seu estado original não adulterado pretendia e garantia certos atributos.
   • A soma total é, 5NF é hoje, o que 3NF pretendia ser 15 anos atrás, e você pode pular as brincadeiras comerciais e as doze ou mais NFs "especiais" (comerciais e pseudo-acadêmicas) no meio, algumas dos quais são identificados na Wikipedia, e mesmo isso em termos confusos.
3. 
   Quinta Forma Normal
   Como você conseguiu entender e implementar o EAV em seu post, não terá problemas para entender o seguinte. Claro que um verdadeiro Modelo Relacional é pré-requisito, chaves fortes, etc. A Quinta Forma Normal é, já que estamos pulando a Quarta:
   
   • Terceira Forma Normal
     • em termos simples e definitivos, cada coluna não chave em cada tabela tem uma relação de 1::1 com a chave primária da tabela,
     • e a nenhuma outra coluna não chave
   • Duplicação zero de dados (o resultado, se a Normalização progredir diligentemente; não alcançada apenas pela inteligência ou experiência, ou trabalhando para isso como uma meta sem o processo formal)
   • sem anomalias de atualização (quando você atualiza uma coluna em algum lugar, não é necessário atualizar a mesma coluna localizada em outro lugar; a coluna existe em um e apenas um lugar).
   • Se você entender o acima, 4NF, BCNF, e todos os "NFs" bobos podem ser dispensados, eles são necessários para Sistemas de Arquivamento de Registros fisicalizados, como promovidos por acadêmicos, bastante estranhos ao Modelo Relacional (Codd).
   l>
4. 
   Sexta forma normal
   
   • O objetivo é a eliminação de dados ausentes (colunas de atributo), também conhecida como eliminação de Nulos
   • Esta é a única solução verdadeira para o Problema Nulo (também chamado de Manipulação de Valores Omissos), e o resultado é um banco de dados sem Nulos. (Isso pode ser feito na 5NF com padrões e substitutos Nulos, mas isso não é o ideal.) Como você interpreta e exibe os valores ausentes é outra história.
   • Tecnicamente, não é uma Forma Normal verdadeira, pois não tem 5NF como pré-requisito, mas tem um valor
5. 
   EAV x Sexta Forma Normal
   Todos os bancos de dados que escrevi, exceto um, são 5NF puros. Trabalhei com (administrei, consertei, aprimorei) alguns bancos de dados EAV e implementei muitos bancos de dados 6NF verdadeiros. O EAV é uma implementação frouxa do 6NF, geralmente feita por pessoas que não têm uma boa compreensão da Normalização e dos NFs, mas que podem ver o valor e precisam da flexibilidade do EAV. Você é um exemplo perfeito.
   
   A diferença é esta:porque é solto, e porque os implementadores não têm uma referência (6NF) para ser fiel, eles só implementam o que precisam, e escrevem tudo em código; que acaba sendo um modelo inconsistente.
   
   Considerando que, uma implementação 6NF pura tem um ponto de referência acadêmico puro e, portanto, geralmente é mais rígida e consistente. Normalmente, isso aparece em dois elementos visíveis:
   
   • 6NF tem um catálogo para conter metadados, e tudo é definido em metadados, não em código. EAV não tem um, tudo está em código (os implementadores mantêm o controle dos objetos e atributos). Obviamente, um catálogo facilita a adição de colunas, a navegação e permite a formação de utilitários.
   • 6NF quando entendido, fornece a verdadeira solução para o problema do nulo. Implementadores de EAV, uma vez que estão ausentes do contexto 6NF, tratam dados ausentes no código, de forma inconsistente, ou pior, permitem Nulos no banco de dados. Os implementadores da 6NF não permitem Nulos e tratam dados ausentes de forma consistente e elegante, sem exigir construções de código (para manipulação de Nulos; você ainda precisa codificar dados ausentes, é claro).