Existuje pro toto schéma databáze název klíčových hodnot?

Hodnota atributu entity (EAV)

Mnoho, včetně mě, je považováno za anti-vzor.

Zde jsou vaše alternativy:

1. použijte databázi dědičnost tabulky

2. použijte data XML a funkce SQLXML

3. použijte databázi nosql, jako je HBase

V PostgreSQL je velmi dobrým způsobem, jak se vypořádat se strukturami EAV, další modul hstore , dostupný pro verze 8.4 nebo novější. Cituji manuál:

Tento modul implementuje datový typ hstore pro ukládání sad párů klíč/hodnota v rámci jedné hodnoty PostgreSQL. To může být užitečné v různých scénářích, jako jsou řádky s mnoha atributy, které jsou zřídka zkoumány, nebo polostrukturovaná data. Klíče a hodnoty jsou jednoduše textové řetězce.

Od Postgresu 9.2 existuje také typ json a hostitel s funkcemi (- - většina z nich byla přidána s 9. ).

Postgres 9.4 přidává (převážně lepší!) Datový typ "binární JSON" jsonb do seznamu možnosti. S pokročilými možnostmi indexu.

Je zvláštní vidět, jak je model EAV db kritizován a někteří dokonce považováni za „anti-model“.

Pokud jde o mě, hlavní nevýhody jsou:

• Výuková křivka je strmější pokud se dostanete na projekt, který již začal používat EAV před nějakou dobou. Opravdu, dotazy jsou těžké, jak výrazně zvýšíte počet spojení (a tabulek), a tak si vyžádáte více času, abyste porozuměli. Stačí se podívat na projekt Magento a podívat se, jak má externí externí projekt těžkou práci na DB, přesto je dokumentace dobře udržovaná.
• Nevhodné pro reportování, pokud potřebujete získat počet lidí, kteří se začali jmenovat „M“ atd ...

Toto řešení byste však rozhodně neměli zahodit, a zde je důvod:

• Simon mluvil o monstra nazvané „měnící se požadavky“. Líbí se mi tento výraz :). A IMHO právě proto může být EAV dobrým kandidátem, protože je to vhodné pro „změnu“, protože můžete přidat tolik atributů, kolik si budete přát. Samozřejmě to záleží na požadavcích, které měníme. Pokud mluvíme o zcela novém podnikání, budete samozřejmě muset zkontrolovat dataModel, ale EAV nabízí velkou flexibilitu. To, že to vyžaduje přísnější, neznamená, že je to méně zajímavé.
• Bylo také řečeno, že „nelze použít datové typy.“ : To je špatně. Můžete mít velmi dobře několik hodnotových tabulek, jednu pro každý typ dataType. Potom musíte v tabulce atributů určit, jaký druh dataType je vaším atributem. Ve skutečnosti kombinace klasického relačního/EAV s třídním vztahem nabízí v designu datové základny spoustu zajímavého potenciálu.

Pokud máte databázi používající strukturu EAV, je možné data dotazovat různými způsoby.

@ Simonova odpověď již ukazuje, jak provést dotaz pomocí více spojení.

Použitá vzorová data:

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);

Pokud používáte RDBMS, který má funkci PIVOT ( SQL Server 2005 + / Oracle 11g + ), můžete data dotazovat následujícím způsobem:

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;

Viz SQL Fiddle s Demo

Pokud nemáte přístup k funkci PIVOT, můžete pro vrácení dat použít agregační funkci s příkazem CASE:

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

Viz SQL Fiddle s Demo

Oba tyto dotazy vrátí data ve výsledku:

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