Antivzor?
V běžném případě je druhá tabulka anti-pattern v kontextu návrhu databáze. A co víc, má konkrétní název:Entity-Attribute-Value (EAV). Jsou případy, kdy je použití tohoto designu oprávněné, ale to jsou vzácné případy – a i tam se tomu lze vyhnout.
Proč je EAV špatná
Podpora integrity dat
Navzdory skutečnosti, že se taková struktura zdá být „flexibilnější“ nebo „pokročilejší“, má tento design slabinu.
- Nelze nastavit povinné atributy . Nemůžete nastavit některý atribut jako povinný, protože atribut je nyní uložen jako řádek – a jediným znakem toho, že atribut není nastaven – je, že v tabulce chybí odpovídající řádek. SQL vám nedovolí vytvořit takové omezení nativně – takže to budete muset zkontrolovat v aplikaci – a ano, pokaždé se dotazovat na tabulku
- Míchání typů dat . Nebudete moci používat standardní datové typy SQL. Protože váš sloupec s hodnotami musí být „supertyp“ pro všechny uložené hodnoty v něm. To znamená - obecně budete muset ukládat všechna data jako raw řetězce . Pak uvidíte, jak bolestivé je pracovat s daty jako s řetězci, pokaždé přehazovat datové typy, kontrolovat integritu dat atd.
- Nelze prosadit referenční neporušenost . V normální situaci můžete použít cizí klíč k omezení vašich hodnot těmi, které jsou definovány v nadřazené tabulce. Ale ne v tomto případě - je to proto, že referenční integrita je aplikována na každý řádek v tabulce, ale ne na hodnoty řádků. Takže – o tuto výhodu přijdete – a to je jedna ze základních ve vztahu DB
- Nelze nastavit názvy atributů . To znamená - nemůžete správně omezit název atributu na úrovni DB. Například napíšete
"customer_name"jako název atributu v prvním případě – a další vývojář to zapomene a použije"name_of_customer". A.. to je v pořádku, DB to projde a skončíte s hodinami strávenými laděním tohoto případu.
Rekonstrukce řady
Navíc rekonstrukce řady bude v běžném případě hrozná. Pokud máte například 5 atributů – to bude 5 samotabulkových JOIN -s. Škoda tak jednoduchého - na první pohled - případu. Nechci si tedy ani představovat, jak budete udržovat 20 atributů.
Lze to odůvodnit?
Jde mi o to - ne. V RDBMS bude vždy existovat způsob, jak se tomu vyhnout. Je to strašné. A pokud je zamýšleno použití EAV, pak může být nejlepší volbou nerelační databáze.