Proč? Proveďte vše vaše entity vyžadují, aby byly tímto způsobem rozšiřitelné? Pravděpodobně ne – ve většině aplikací existuje nanejvýš jedna nebo dvě entity, kterým by tato úroveň flexibility prospěla. Ostatní entity ve skutečnosti těží ze stability a jasnosti ne se neustále mění.
EAV je příkladem Efektu vnitřní platformy :
Jinými slovy, nyní je vaší odpovědností napsat aplikační kód tak, aby dělal všechny věci, které správný RDBMS již poskytuje, jako jsou omezení a datové typy. Dokonce i něco tak jednoduchého, jako je vytvoření povinného sloupce, jako je NOT NULL nefunguje v EAV.
Je pravda, že někdy projekt vyžaduje mnoho tabulek. Ale klamete sami sebe, pokud si myslíte, že jste projekt zjednodušili vytvořením pouhých dvou tabulek. Stále budete mít tolik odlišných entit, jako byste měli stolů, ale nyní je na vás, abyste je uchránili, aby se neměnily v hromadu odpadků.
Než investujete příliš mnoho času do EAV, přečtěte si tento příběh o společnosti, která málem přestala fungovat, protože se někdo pokusil učinit jejich úložiště dat libovolně flexibilní:Špatná CaRMa .
Více o EAV jsem také napsal v blogovém příspěvku EAV FAIL a v kapitole mé knihy SQL Antipatterns:Vyhýbání se nástrahám databázového programování .