Zelfs als uw gebruikersnaam uniek is, heeft het weinig voordelen om een extra id-kolom te hebben in plaats van de varchar als uw primaire sleutel te gebruiken.
-
Sommige mensen geven er de voorkeur aan om een integerkolom als primaire sleutel te gebruiken, om te dienen als een surrogaatsleutel die nooit hoeft te veranderen, zelfs als andere kolommen aan verandering onderhevig zijn. Hoewel niets verhindert dat een natuurlijke primaire sleutel ook kan worden gewijzigd, moet u trapsgewijze beperkingen voor externe sleutels gebruiken om ervoor te zorgen dat de externe sleutels in gerelateerde tabellen synchroon worden bijgewerkt met een dergelijke wijziging.
-
De primaire sleutel die een 32-bits geheel getal is in plaats van een varchar, kan ruimte besparen. De keuze tussen een int of een varchar refererende sleutelkolom in elke andere tabel die naar uw gebruikerstabel verwijst, kan een goede reden zijn.
-
Invoegen in de primaire sleutelindex is een beetje efficiënter als u nieuwe rijen aan het einde van de index toevoegt, in plaats van ze in het midden van de index te plaatsen. Indexen in MySQL-tabellen zijn meestal B+Tree-gegevensstructuren en u kunt deze bestuderen om te begrijpen hoe ze presteren.
-
Sommige applicatieframeworks geven de voorkeur aan de afspraak dat elke tabel in uw database een primaire sleutelkolom heeft met de naam
id, in plaats van natuurlijke sleutels of samengestelde sleutels te gebruiken. Het volgen van dergelijke conventies kan bepaalde programmeertaken eenvoudiger maken.
Geen van deze problemen zijn dealbreakers. En er zijn ook voordelen aan het gebruik van natuurlijke sleutels:
-
Als u rijen vaker op gebruikersnaam opzoekt dan op id, kan het beter zijn om de gebruikersnaam als de primaire sleutel te kiezen en te profiteren van de geïndexeerde opslag van InnoDB. Maak indien mogelijk uw primaire opzoekkolom de primaire sleutel, omdat het opzoeken van primaire sleutels efficiënter is in InnoDB (u zou InnoDB in MySQL moeten gebruiken).
-
Zoals je hebt opgemerkt, lijkt het zonde van de opslagruimte om een extra id-kolom te bewaren die je niet nodig hebt als je al een unieke beperking hebt op de gebruikersnaam.
-
Het gebruik van een natuurlijke sleutel betekent dat externe sleutels een door mensen leesbare waarde bevatten, in plaats van een willekeurig geheel getal id. Hierdoor kunnen query's de waarde van de refererende sleutel gebruiken zonder terug te hoeven gaan naar de bovenliggende tabel voor de "echte" waarde.
Het punt is dat er geen regel is die 100% van de gevallen dekt. Ik raad je vaak aan om je opties open te houden en natuurlijke sleutels, samengestelde sleutels en surrogaatsleutels te gebruiken, zelfs in een enkele database.
Ik behandel enkele problemen met surrogaatsleutels in het hoofdstuk "ID vereist" in mijn boek SQL Antipatterns:Avoiding de valkuilen van databaseprogrammering .