Re-Seed der Identitätsspalte: Wann ist es notwendig?

Während einer der letzten Lektionen an der Universität (ich bin Student) bat uns der Dozent, eine Datenbank (MySQL Server, wenn es darauf ankommt) und eine winzige Client-App zu entwickeln, die die Datenbank als Datenquelle verwendet.

Eine der Anforderungen war, dass die Identitätsspalte (die die PK in jeder Tabelle ist) sequentiell sein muss, da dies eine gute Praxis ist (gemäß den Worten des Dozenten). Das heißt, wenn die Tabellenzeile gelöscht wird, muss die PK in nachfolgenden Einfügungen wiederverwendet werden. Ich habe durchschnittliche Kenntnisse in RDBMS, PKs und Identitätsspalten. Soweit ich weiß, ist diese Identitätsspalte nur eine Möglichkeit, die DB beim Einfügen von Zeilen automatisch PKs generieren zu lassen, und nicht mehr. Der Wert der Identitätsspalte darf in keiner Weise mit Zeilenattributen in Beziehung stehen (solange es sich nicht um einen natürlichen Schlüssel handelt).

Diese Anforderung (streng sequentielle Identitätsspalte) war mir verdächtig. Ich habe versucht, den Dozenten zu fragen, was falsch ist, wenn die Identität nicht sequentiell ist (mit Lücken, die durch Löschungen verursacht werden), erhielt jedoch eine sehr abstrakte Antwort wie "Es ist praktisch für Benutzer und nützlich für DB-Administratoren, die die Datenbank verwalten". Keine konkreten Beispiele. Das Argument "praktisch für Benutzer" klingt albern, weil es im Geschäftsbereich keine Bedeutung hat.

Deshalb bin ich neugierig, ob diese Gründe real sind? Ich kann mir nur einen Fall vorstellen, in dem eine erneute Eingabe der Identitätsspalte erforderlich ist - wenn der Identitätsraum erschöpft ist. Dies ist jedoch ein größeres Designproblem, wenn der Identitätsspaltentyp falsch ausgewählt wurde, z. B. einfach intanstelle von bigintoder uniqueidentifierwenn die Tabelle Milliarden Zeilen enthält. Angenommen, eine Identitätsspalte ist ein Clustered-Index: Können Lücken in der Identitätsspalte die Indexleistung beeinflussen? Vielleicht gibt es andere reale Gründe für das automatische erneute Setzen von Identitätsspalten nach jedem Löschen, das mir nicht bekannt ist?

Danke im Voraus!

Das heißt, wenn die Tabellenzeile gelöscht wird, muss die PK in nachfolgenden Einfügungen wiederverwendet werden.

Aus welchem ​​Universum stammt dein Dozent?

Das ist grob ineffizient. Wenn Sie dies versuchen, verringern Sie Ihre Leistungsaussichten um den Faktor 10.

Wenn Sie aus Überwachungsgründen lückenlose Nummern benötigen, erstellen Sie diese explizit und nicht direkt aus Datenbank-Tools. Und löschen Sie niemals Zeilen, sondern kennzeichnen Sie sie als "gelöscht". Dies erhöht die Unordnung von Abfragen, da sie solche Zeilen ignorieren müssen.

In MySQL erfordert InnoDB das Vorhandensein einer eindeutigen PRIMARY KEYTabelle. Aber das ist das Ausmaß der Anforderung. Der Schlüssel kann sogar eine Zeichenfolge sein.

Lücken sind eine Annehmlichkeit für die Benutzer und Datenbankadministratoren, keine Unannehmlichkeit.

Ich kann mir einen Fall vorstellen, in dem lückenlos wäre - in Gruppen von jeweils 100 Reihen aufzuteilen. Es gibt jedoch eine einfache Problemumgehung LIMIT 100,1.

Lücken haben keinen Einfluss auf die Leistung. Dies schließt nicht numerische Indizes ein. Und nicht eindeutige Indizes. Und zusammengesetzte Indizes.

Sicher, Ihnen können die IDs ausgehen. Ich glaube, ich habe es in fast zwei Jahrzehnten mit MySQL zweimal gesehen. Ich kann mir genauso gut Sorgen machen, von einem Asteroiden getroffen zu werden. Es steht auf meiner Liste der Dinge, die mich nachts wach halten.

Lücken entstehen aus (mindestens): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(explizit oder durch Absturz), Multi-Master - Replikation (einschließlich Galera und Gruppen Replication). Möchten Sie wirklich Problemumgehungen für diese finden?!

Lassen Sie uns alles überprüfen, was der Dozent als verdächtig bezeichnet.

Von der Wiederverwendung eines Identitätswerts sollte generell abgeraten werden. Entweder wird der Wert vollständig intern verwendet. In diesem Fall ist sein tatsächlicher Wert unerheblich, oder er wird auch extern verwendet. In diesem Fall führt die Wiederverwendung des Werts sehr wahrscheinlich zu einer falschen Identifizierung.

Nehmen wir den offensichtlichen Fall einer Rechnung oder Bestellnummer, diese stammen möglicherweise leicht aus einer Identitätsspalte und werden extern angezeigt, aber Sie möchten sie aus genau diesem Grund niemals wiederverwenden. Beide beziehen sich auf bestimmte Transaktionen, die Sie nicht verwirren möchten.

Die Lösung solcher Probleme kann ein großer Aufwand sein, wenn Unternehmen fusionieren oder übernommen werden. Solche Probleme absichtlich schaffen? Nicht weise.

Die Wiederverwendung von PK-ID-Werten ist problematisch und sollte generell vermieden werden.

Erstens bietet die Implementierung von auto_increment-Spalten keine Garantie dafür, dass sie lückenlos sind. In der Tat treten Lücken auf, wenn Sie eine Einfügung in eine automatische Inkrementierungsspalte zurücksetzen.

Zweitens kann sich die Lücken-ID auf vorhandene Daten beziehen, die nicht gelöscht wurden (aufgrund fehlender FK-Einschränkungen). Wenn sie in Mitgliedsnummern übersetzt werden, die außerhalb des Systems kommuniziert werden, birgt dies potenzielle Risiken für die Geschäftsidentität.

Drittens bigint unsignedwerden die IDs auch bei einer extrem hohen Einfügungsrate nicht für längere Zeit ausgehen.

Der größte Schmerz mit Lücken besteht darin, auf Prüfer zu stoßen, die darauf bestehen, dass es sich um einen Prüfungsfehler handelt. Für DBAs wissen sie, dass Lücken bestehen und warum.

Ich werde nicht die Kommentare aller anderen wiederholen, dass die Wiederverwendung einer PK eine schlechte Idee ist, aber ich bin auf Zeiten gestoßen, in denen eine Identitätsspalte neu gesetzt werden musste.

Beschädigung des PK-Index selbst.

Zugegeben, dies war MS-SQL und vor vielen, vielen Jahren, aber es ist immer noch relevant. Vor vielen Jahren hielt es jemand für das Unternehmen, für das ich arbeite, für eine gute Idee, PCs als Server an mehr als 150 entfernten Standorten wiederzuverwenden, nachdem sie zu alt waren, um von den Kunden verwendet zu werden, und sie dann in einen Schrank zu stecken ohne Belüftung. Wenn nein Weil wir alle wissen, dass ein Haufen 10 Jahre alter Junk-Computer in einem winzigen Raum mit Temperaturen von über 120, in denen geschäftskritische Datenbanken ausgeführt werden, nur zu guten Ergebnissen führen kann. Wie 40% Ausfallraten und ich überdenke meine Berufswahl. Wir würden die Daten zurück in die Unternehmenszentrale replizieren, aber meistens würden diese Fehler dazu führen, dass den Datenbanken schlimme Dinge passieren. Eines dieser Dinge war die Datenbank mit beschädigten Indizes, die die Datenbank und den Replikationsprozess belegen würden. Zweimal in dieser großartigen Umgebung bestand die einzige Lösung zur Behebung der Replikation darin, die Indizes neu zu sortieren und dann die Replikation wiederherzustellen. Wir haben die Server später ausgetauscht, bevor wir sie komplett über Bord geworfen haben.