Existe um nome para esse esquema de banco de dados de valores-chave?

Chama-se Entidade-Atributo-Valor (às vezes também 'pares nome-valor') e é um caso clássico de "um pino redondo em um buraco quadrado" quando as pessoas usam o padrão EAV em um banco de dados relacional.

Aqui está uma lista de por que você não deve usar o EAV:

• Você não pode usar tipos de dados. Não importa se o valor é uma data, um número ou dinheiro (decimal). Sempre será forçado a varchar. Isso pode ser qualquer coisa, desde um pequeno problema de desempenho até uma enorme dor de barriga (já teve que perseguir uma variação de um centavo em um relatório mensal de resumo?).
• Você não pode (facilmente) impor restrições. Requer uma quantidade ridícula de código para impor "Todos precisam ter uma altura entre 0 e 3 metros" ou "A idade não deve ser nula e >= 0", em oposição às 1-2 linhas que cada uma dessas restrições seria em um sistema devidamente modelado.
• Relacionado ao acima, você não pode garantir facilmente que obterá as informações necessárias para cada cliente (a idade pode estar faltando em um, o próximo pode estar sem a altura, etc.). Você pode fazer isso, mas é muito mais difícil do que SELECT height, weight, age FROM Client where height is null or weight is null.
• Relacionado novamente, dados duplicados são muito mais difíceis de detectar (o que acontece se eles fornecerem duas idades para um cliente? Desfazer o EAV dos dados, conforme abaixo, fornecerá duas linhas de resultados se você tiver um atributo duplicado. Se um cliente tiver duas entradas separadas para dois atributos, você obterá quatro linhas da consulta abaixo).
• Você nem pode garantir que os nomes dos atributos sejam consistentes. "Age_yr" pode se tornar "AGE_IN_YEARS" ou "age". (Reconhecidamente, isso é menos problemático quando você está recebendo uma extração do que quando as pessoas estão inserindo dados, mas ainda assim.)
• Qualquer tipo de consulta não trivial é um desastre completo. Para relacionar um sistema EAV de três atributos para que você possa consultá-lo de maneira racional, são necessárias três junções da tabela EAV.

Comparar:

SELECT cID.ID AS [ID], cH.Value AS [Height], cW.Value AS [Weight], cA.Value AS [Age]
FROM (SELECT DISTINCT ID FROM Client) cID 
      LEFT OUTER JOIN 
    Client cW ON cID.ID = cW.ID AND cW.Metric = "Wt_kg" 
      LEFT OUTER JOIN 
    Client cH ON cID.ID = cH.ID AND cW.Metric = "Ht_cm" 
      LEFT OUTER JOIN 
    Client cA ON cID.ID = cA.ID AND cW.Metric = "Age_yr"

Para:

SELECT c.ID, c.Ht_cm, c.Wt_kg, c.Age_yr
FROM Client c

Aqui está uma lista (muito curta) de quando você deve usar o EAV:

• Quando não há absolutamente nenhuma maneira de contornar isso e você precisa oferecer suporte a dados sem esquema em seu banco de dados.
• Quando você só precisa armazenar "coisas" e não espera precisar delas de uma forma mais estruturada. Cuidado, porém, o monstro chamado "mudança de requisitos".

Sei que acabei de passar este post inteiro detalhando por que o EAV é uma péssima ideia na maioria dos casos - mas há alguns casos em que é necessário/inevitável. no entanto, na maioria das vezes (incluindo o exemplo acima), será muito mais trabalhoso do que compensador. Se você tiver um requisito para amplo suporte de entrada de dados do tipo EAV, deve procurar armazená-los em um sistema de valor-chave, por exemplo, Hadoop/HBase, CouchDB, MongoDB, Cassandra, BerkeleyDB.

Valor do Atributo da Entidade (EAV)

É considerado um antipadrão por muitos, inclusive eu.

Aqui estão suas alternativas:

1. usar herança de tabela de banco de dados

2. usar dados XML e funções SQLXML

3. use um banco de dados nosql, como HBase

No PostgreSQL, uma forma muito boa de lidar com estruturas EAV é o módulo adicional hstore, disponível a partir da versão 8.4 ou posterior. O manual:

Este módulo implementa o hstoretipo de dados para armazenar conjuntos de pares chave/valor dentro de um único valor PostgreSQL. Isso pode ser útil em vários cenários, como linhas com muitos atributos que raramente são examinados ou dados semiestruturados. Chaves e valores são simplesmente strings de texto.

Requer o módulo adicional hstore. Ver:

• Pares de chave-valor no PostgreSQL

Desde o Postgres 9.2, há também o jsontipo e uma série de funcionalidades para acompanhá-lo (a maior parte adicionada com o 9.3 ).

O Postgres 9.4 adiciona o tipo de dados "JSON binário" (muito superior) jsonb. Com opções avançadas de índice.

Engraçado ver como o modelo EAV db é criticado e até considerado um "anti-padrão" por alguns.

No que me diz respeito, as principais desvantagens são:

• A curva de aprendizado é mais íngreme se você entrar em um projeto que já começou a usar o EAV há algum tempo. De fato, as consultas são difíceis , pois você aumenta muito o número de junções (e tabelas) e, portanto, exigirá mais tempo para você entender. Basta dar uma olhada no projeto Magento e ver como o desenvolvedor externo ao projeto tem dificuldade em trabalhar no banco de dados, mas a documentação é bem sustentada.
• Não é adequado para relatórios , se você precisar obter o número de pessoas cujo nome começa com "M" etc...

No entanto, você definitivamente não deve descartar esta solução, e aqui está o porquê:

• Simon falou sobre o monstro chamado "mudança de requisitos". Eu gosto dessa expressão :). E IMHO é exatamente por isso que o EAV pode ser um bom candidato, porque é adequado para "mudança" , pois você pode adicionar quantos atributos desejar com bastante facilidade. Claro que depende dos requisitos que estamos mudando. Se estamos falando de um negócio totalmente novo, é claro que você terá que revisar seu dataModel, mas o EAV oferece muita flexibilidade. Só porque pede mais rigor, não significa que seja menos interessante.
• Também foi dito que "Você não pode usar tipos de dados". : Isso está errado . Você pode muito bem ter várias tabelas de valores , uma para cada tipo de dados. Em seguida, você deve especificar em sua tabela de atributos qual tipo de dataType é seu atributo. Na verdade, uma mistura de relacional/EAV clássico com relacionamento de classe oferece muito potencial interessante no projeto de banco de dados.

Se você tiver um banco de dados que esteja usando a estrutura EAV, é possível consultar os dados de várias maneiras.

A resposta de @ Simon já mostra como realizar uma consulta usando várias junções.

Dados de amostra usados:

CREATE TABLE yourtable ([ID] int, [Metric] varchar(6), [Value] int);

INSERT INTO yourtable ([ID], [Metric], [Value])
VALUES (1, 'Ht_cm', 190),
    (1, 'Wt_kg', 82),
    (1, 'Age_yr', 43),
    (2, 'Ht_cm', 170),
    (2, 'Wt_kg', 60),
    (2, 'Age_yr', 22),
    (3, 'Ht_cm', 205),
    (3, 'Wt_kg', 90),
    (3, 'Age_yr', 51);

Se você estiver usando um RDBMS que tenha uma PIVOTfunção ( SQL Server 2005+ / Oracle 11g+ ), poderá consultar os dados da seguinte maneira:

select id, Ht_cm, Wt_kg, Age_yr
from
(
  select id, metric, value
  from yourtable
) src
pivot
(
  max(value)
  for metric in (Ht_cm, Wt_kg, Age_yr)
) piv;

Consulte SQL Fiddle com demonstração

Se você não tiver acesso a uma PIVOTfunção, poderá usar uma função agregada com uma CASEinstrução para retornar os dados:

select id,
  max(case when metric ='Ht_cm' then value else null end) Ht_cm,
  max(case when metric ='Wt_kg' then value else null end) Wt_kg,
  max(case when metric ='Age_yr' then value else null end) Age_yr
from yourtable
group by id

Consulte SQL Fiddle com demonstração

Ambas as consultas retornarão dados no resultado:

| ID | HT_CM | WT_KG | AGE_YR |
-------------------------------
|  1 |   190 |    82 |     43 |
|  2 |   170 |    60 |     22 |
|  3 |   205 |    90 |     51 |