Спазвам няколко правила:
- Първичните ключове трябва да са толкова малки, колкото е необходимо. Предпочитайте числов тип, защото числовите типове се съхраняват в много по-компактен формат от символните формати. Това е така, защото повечето първични ключове ще бъдат външни ключове в друга таблица, както и използвани в множество индекси. Колкото по-малък е ключът ви, толкова по-малък е индексът, толкова по-малко страници в кеша ще използвате.
- Първичните ключове никога не трябва да се променят. Актуализирането на първичен ключ винаги не трябва да става дума. Това е така, защото е най-вероятно да се използва в множество индекси и да се използва като външен ключ. Актуализирането на един първичен ключ може да причини вълнообразен ефект на промените.
- НЕ използвайте „първичен ключ на проблема“ като първичен ключ на логическия модел. Например номер на паспорт, номер на социално осигуряване или номер на договора на служителя, тъй като тези „естествени ключове“ могат да се променят в реални ситуации. Не забравяйте да добавите УНИКАЛНИ ограничения за тях, където е необходимо, за да наложите последователност.
За сурогатен срещу естествен ключ се позовавам на правилата по-горе. Ако естественият ключ е малък и никога няма да се промени, той може да се използва като първичен ключ. Ако естественият ключ е голям или има вероятност да се промени, използвам сурогатни ключове. Ако няма първичен ключ, аз все още правя сурогатен ключ, защото опитът показва, че винаги ще добавяте таблици към схемата си и искате да поставите първичен ключ на място.
