Ne, toto je špatný návrh relační databáze. Toto je příklad Entity-Attribute-Value design. Je flexibilní, ale porušuje většinu pravidel toho, co to znamená být relační databází.
Než se pustíte do návrhu EAV jako řešení pro flexibilní databázi, přečtěte si tento příběh:Špatná CaRMa .
Konkrétněji, některé z problémů s EAV zahrnují:
- Nevíte, jaké atributy existují pro dané ID_NUM, aniž byste se na ně zeptali.
- Žádný atribut nelze nastavit jako povinný, což je ekvivalent NOT NULL.
- Nemůžete používat databázová omezení.
- Nemůžete používat datové typy SQL;
valuesloupec musí být dlouhý VARCHAR. - Zejména v MySQL je každý VARCHAR uložen na své vlastní datové stránce, takže je to velmi plýtvání.
Dotazy jsou také neuvěřitelně složité, když používáte návrh EAV. Magento, platforma elektronického obchodování s otevřeným zdrojovým kódem, široce využívá EAV a mnoho uživatelů říká, že pokud potřebujete vlastní přehledy, dotazování je velmi pomalé a obtížné.
Chcete-li být relační, měli byste každý jiný atribut uložit do vlastního sloupce s vlastním názvem a vhodným datovým typem.
Více o EAV jsem napsal ve své prezentaci Praktické objektově orientované Modely v SQL a v mém příspěvku na blogu EAV FAIL a v mé knize SQL Antipatterns:Vyhýbání se nástrahám databázového programování .