De DB moet een B-Tree . onderhouden (of een vergelijkbare structuur) met de sleutel op een manier om ze te ordenen.
Als de sleutel is gehasht en opgeslagen in de B-Tree, zou het goed zijn om snel de uniciteit te controleren van de sleutel -- de sleutel kan nog steeds efficiënt worden opgezocht. Maar u zou niet efficiënt kunnen zoeken naar bereik van gegevens (bijvoorbeeld met LIKE ) omdat de B-Tree niet meer geordend is volgens de String-waarde.
Dus ik denk dat de meeste DB de String echt in de B-Tree opslaan, wat (1) meer ruimte kan innemen dan numerieke waarden en (2) vereisen dat de B-Tree opnieuw in evenwicht wordt gebracht als sleutels in willekeurige volgorde worden ingevoegd (geen notie van toenemende waarde zoals bij numerieke pk).
De straf in de praktijk kan variëren van onbeduidend tot enorm. Het hangt allemaal af van het gebruik, het aantal rijen, de gemiddelde grootte van de tekenreekssleutel, de query's die deelnemen aan de tabel, enz.