DB трябва да поддържа B-дърво (или подобна структура) с ключа по начин, по който да ги поръчате.
Ако ключът е хеширан и съхранен в B-дървото, би било добре да проверите бързо уникалността на ключа - ключът все още може да се търси ефективно. Но няма да можете да търсите ефективно за обхват от данни (например с LIKE ), тъй като B-дървото вече не е подредено според стойността на низа.
Така че мисля, че повечето DB наистина съхраняват низа в B-дървото, което може (1) да заеме повече пространство отколкото числовите стойности и (2) изискват B-дървото да бъде ребалансирано ако ключовете са вмъкнати в произволен ред (няма идея за увеличаване на стойността, както при числовия pk).
наказанието на практика може да варира от незначително до огромно. Всичко зависи от употребата, броя на редовете, средния размер на низовия ключ, заявките, които обединяват таблицата и т.н.
