Não, este é um design ruim para um banco de dados relacional. Este é um exemplo do Entity-Attribute-Value Projeto. É flexível, mas quebra a maioria das regras do que significa ser um banco de dados relacional.

Antes de mergulhar no design EAV como uma solução para um banco de dados flexível, leia esta história:Mau Carma .

Mais especificamente, alguns dos problemas com EAV incluem:

• Você não sabe quais atributos existem para um determinado ID_NUM sem consultá-los.
• Você não pode tornar nenhum atributo obrigatório, o equivalente a NOT NULL.
• Você não pode usar restrições de banco de dados.
• Você não pode usar tipos de dados SQL; o value coluna deve ser um VARCHAR longo.
• Particularmente no MySQL, cada VARCHAR é armazenado em sua própria página de dados, então isso é um grande desperdício.

As consultas também são incrivelmente complexas quando você usa o design EAV. Magento, uma plataforma de comércio eletrônico de código aberto, usa EAV extensivamente, e muitos usuários dizem que é muito lento e difícil de consultar se você precisar de relatórios personalizados.

Para ser relacional, você deve armazenar cada atributo diferente em sua própria coluna, com seu próprio nome e um tipo de dados apropriado.

Escrevi mais sobre EAV em minha apresentação Practical Object-Oriented Modelos em SQL e em minha postagem no blog EAV FAIL , e em meu livro, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .