Antipadrão?
Em casos comuns, a segunda tabela é antipadrão no contexto do projeto de banco de dados. E, ainda mais, tem um nome específico:Entity-Attribute-Value (EAV). Existem alguns casos em que o uso desse design é justificado, mas são casos raros - e mesmo assim pode ser evitado.
Por que o EAV é ruim
Suporte de integridade de dados
Apesar de tal estrutura parecer mais "flexível" ou "avançada", esse design tem pontos fracos.
- Impossível fazer atributos obrigatórios . Você não pode tornar algum atributo obrigatório, pois o atributo agora é armazenado como uma linha - e o único sinal de que o atributo não está definido - é que a linha correspondente está ausente na tabela. O SQL não permitirá que você construa tal restrição nativamente - portanto, você terá que verificar isso no aplicativo - e, sim, consultar sua tabela a cada vez
- Mistura de tipos de dados . Você não poderá usar tipos de dados padrão SQL. Porque sua coluna de valor deve ser um "supertipo" para todos os valores armazenados nela. Isso significa que, em geral, você terá que armazenar todos os dados como strings brutas . Então você verá como é difícil trabalhar com datas como com strings, lançando tipos de dados a cada vez, verificando a integridade dos dados etc.
- Impossível impor integridade referencial . Em situação normal, você pode usar a chave estrangeira para restringir seus valores por aqueles definidos na tabela pai. Mas não neste caso - porque a integridade referencial é aplicada a cada linha na tabela, mas não para valores de linha. Então - você perderá essa vantagem - e é um dos fundamentos em relação DB
- Impossível definir nomes de atributos . Isso significa - você não pode restringir o nome do atributo no nível do banco de dados corretamente. Por exemplo, você escreverá
"customer_name"como nome do atributo no primeiro caso - e outro desenvolvedor esquecerá isso e usará"name_of_customer". E .. tudo bem, o DB passará isso e você terminará com horas gastas na depuração deste caso.
Reconstrução de linha
Além disso, a reconstrução de linha será terrível em casos comuns. Se você tiver, por exemplo, 5 atributos - serão 5 self-table
JOIN -s. Muito ruim para um caso tão simples - à primeira vista. Então eu não quero nem imaginar como você vai manter 20 atributos. Pode ser justificado?
Meu ponto é - não. No RDBMS sempre haverá uma maneira de evitar isso. É horrível. E se EAV se destina a ser usado, a melhor escolha pode ser não relacional bancos de dados.
