Ich befolge ein paar Regeln:
- Primärschlüssel sollten so klein wie nötig sein. Bevorzugen Sie einen numerischen Typ, da numerische Typen in einem viel kompakteren Format gespeichert werden als Zeichenformate. Dies liegt daran, dass die meisten Primärschlüssel Fremdschlüssel in einer anderen Tabelle sind und in mehreren Indizes verwendet werden. Je kleiner Ihr Schlüssel, desto kleiner der Index, desto weniger Seiten im Cache werden Sie verwenden.
- Primärschlüssel sollten sich niemals ändern. Das Aktualisieren eines Primärschlüssels sollte immer ausgeschlossen sein. Dies liegt daran, dass er höchstwahrscheinlich in mehreren Indizes verwendet und als Fremdschlüssel verwendet wird. Das Aktualisieren eines einzelnen Primärschlüssels kann zu einem Welleneffekt von Änderungen führen.
- Verwenden Sie NICHT „Ihren problematischen Primärschlüssel“ als Primärschlüssel Ihres Logikmodells. Zum Beispiel Passnummer, Sozialversicherungsnummer oder Mitarbeitervertragsnummer, da sich diese „natürlichen Schlüssel“ in realen Situationen ändern können. Stellen Sie sicher, dass Sie UNIQUE-Einschränkungen für diese hinzufügen, wo dies erforderlich ist, um Konsistenz zu erzwingen.
In Bezug auf Ersatz- und natürlichen Schlüssel beziehe ich mich auf die obigen Regeln. Wenn der natürliche Schlüssel klein ist und sich nie ändert, kann er als Primärschlüssel verwendet werden. Wenn der natürliche Schlüssel groß ist oder sich wahrscheinlich ändern wird, verwende ich Ersatzschlüssel. Wenn es keinen Primärschlüssel gibt, erstelle ich trotzdem einen Ersatzschlüssel, weil die Erfahrung zeigt, dass Sie Ihrem Schema immer Tabellen hinzufügen und sich wünschen, Sie würden einen Primärschlüssel einsetzen.
