Ein praktisches Beispiel für die Bewältigung von Kompromissen bei der Schlüsselauswahl in einem realen Szenario
Kürzlich hatte ich die Gelegenheit, ein einfaches Chatsystem zu entwerfen und zu integrieren. Während ich die Architektur skizzierte, verbrachte ich viel Zeit damit, über die Auswahl der Primärschlüssel nachzudenken. Dieses Thema scheint immer wieder aufzutauchen, und als ich andere Artikel las, wurde mir klar, dass es tiefer geht, als ich zuvor angenommen hatte. Obwohl ich kein völliges Neuland im Bereich Datendesign und seiner zahlreichen Fallstricke bin, conflict mir nie ganz klar, welche tiefgreifenden Auswirkungen die Auswahl der Primärschlüssel auf die Systemleistung und Skalierbarkeit hat. In diesem Artikel möchte ich meine Gedanken zu den von mir getroffenen Entscheidungen und den dahinter stehenden Überlegungen mit Ihnen teilen.
Es ist wichtig zu beachten, dass ich mit Postgres arbeite. Obwohl ich glaube, dass der Großteil dieses Artikels auf andere Datenbanken angewendet werden kann, werde ich dieses entscheidende Element gelegentlich ignorieren und die Argumente auf einer höheren Ebene diskutieren. Bedenken Sie jedoch, dass einige Argumente außerhalb von Postgres möglicherweise nicht anwendbar sind.
Meine Arbeit konzentrierte sich auf die Integration einer neuen Funktion in ein bestehendes, ausgereiftes System, was bedeutet, dass für die beteiligten Einheiten bereits eine beträchtliche Menge an Kontext vorhanden ist. Die folgende Abbildung und die Annahmen bieten eine vereinfachte Momentaufnahme des mentalen Modells …