Proč bychom měli mít v tabulce uživatelů sloupec ID?

I když je vaše uživatelské jméno jedinečné, existuje několik výhod, když budete mít další sloupec id namísto použití varchar jako primárního klíče.

• Někteří lidé dávají přednost použití celočíselného sloupce jako primárního klíče, který slouží jako náhradní klíč, který se nikdy nemusí měnit, i když se mohou změnit i jiné sloupce. Ačkoli nic nebrání tomu, aby byl měněn i přirozený primární klíč, budete muset použít kaskádová omezení cizích klíčů, abyste zajistili, že cizí klíče v souvisejících tabulkách budou aktualizovány synchronizovaně s každou takovou změnou.

• Primární klíč, který je 32bitovým celým číslem namísto varchar, může ušetřit místo. Volba mezi sloupcem cizího klíče int nebo varchar v každé druhé tabulce, která odkazuje na vaši uživatelskou tabulku, může být dobrým důvodem.

• Vkládání do indexu primárního klíče je o něco efektivnější, pokud přidáte nové řádky na konec indexu, než když je vklíníte doprostřed indexu. Indexy v tabulkách MySQL jsou obvykle datové struktury B+Tree a můžete si je prostudovat, abyste pochopili, jak fungují.

• Některé aplikační rámce preferují konvenci, že každá tabulka ve vaší databázi má sloupec primárního klíče s názvem id namísto použití přirozených klíčů nebo složených klíčů. Dodržování těchto konvencí může některé programovací úlohy zjednodušit.

Žádný z těchto problémů nenarušuje dohodu. A používání přirozených klíčů má také výhody:

• Pokud vyhledáváte řádky podle uživatelského jména častěji než podle id, může být lepší zvolit uživatelské jméno jako primární klíč a využít indexově organizované úložiště InnoDB. Pokud je to možné, nastavte primární vyhledávací sloupec jako primární klíč, protože vyhledávání primárního klíče je efektivnější v InnoDB (v MySQL byste měli používat InnoDB).

• Jak jste si všimli, pokud již máte jedinečné omezení na uživatelské jméno, zdá se, že je plýtváním úložištěm uchovávat další sloupec id, který nepotřebujete.

• Použití přirozeného klíče znamená, že cizí klíče obsahují lidsky čitelnou hodnotu namísto libovolného id celého čísla. To umožňuje dotazům používat hodnotu cizího klíče, aniž by se musely připojovat zpět k nadřazené tabulce pro „skutečnou“ hodnotu.

Jde o to, že neexistuje žádné pravidlo, které by pokrývalo 100 % případů. Často doporučuji, abyste měli své možnosti otevřené a používali přirozené klíče, složené klíče a náhradní klíče i v jediné databázi.

Některým problémům s náhradními klíči se věnuji v kapitole „Vyžadováno ID“ ve své knize SQL Antipatterns:Avoiding úskalí databázového programování .