Datentypen für Pass und Identifikatoren in SQL: Speicherfehler

Datentypen für IDs: Warum Passnummern keine Ganzzahlen sind

Eine einfache Frage zur Auswahl des richtigen Datentyps für die Speicherung von Passnummern in einer SQL-Datenbank teilt Entwickler in zwei Lager: diejenigen, die über die Semantik der Daten nachdenken, und diejenigen, die nach Schema F vorgehen. Die Wahl von INTEGER statt VARCHAR entfernt führende Nullen und zerstört die Identifikation – entscheidend in Systemen mit Millionen von Nutzern. Dieser Artikel zerlegt ein Kernprinzip des Datenbankschemadesigns basierend auf der Natur der Daten, nicht ihrem Aussehen.

Daten-Semantik vs. Aussehen

Die meisten Entwickler greifen bei der Sicht auf Ziffern in einer Passnummer in Vorstellungsgesprächen instinktiv zu numerischen Typen wie INTEGER oder BIGINT. Das ist ein klassischer Fehler aus oberflächlicher Analyse. Die entscheidende Frage ist nicht, woraus die Daten bestehen, sondern wie sie verwendet werden. Man führt nie Rechenoperationen mit Passserien oder -nummern durch – man vergleicht nur auf Gleichheit, sucht und überträgt sie. Das sind Identifikatoren, keine Mengen. Die richtige Wahl ist daher ein String-Typ: CHAR(4) für die Serie und CHAR(6) für die Nummer oder CHAR(10) für den kombinierten Wert. Die Speicherung als INTEGER entfernt führende Nullen unwiderruflich: 0306 wird zu 306 und macht das Dokument ungültig, ohne protokollierte Fehler.

Realwelt-Folgen des Fehlers

Die falsche Wahl des Datentyps ist keine Theorie – sie schlägt in der Produktion regelmäßig zu. Nehmen Sie einen Parkscheinautomatendienst, bei dem das Passfeld als NUMBER eine führende Null stillschweigend kürzte und Datenbankeinträge mit Papierdokumenten nicht mehr übereinstimmten. Es schlüpfte durch Code-Review und Tests, bis es Nutzer mit nullbeginnenden Serien traf. In Russland gibt es Millionen solcher Pässe, was das Problem massiv skaliert. Optimierungsargumente wie Speicherersparnis oder Indexgeschwindigkeit halten nicht stand:

• CHAR(4) benötigt dieselben 4 Bytes wie INTEGER für einbyteige Ziffern.
• VARCHAR-Indizes arbeiten mit O(log n)-Effizienz, genau wie numerische, mit vernachlässigbaren Unterschieden bei festen Strings.

Byteersparnisse rechtfertigen keine Datenverlustrisiken.

Die Regel auf andere Identifikatoren anwenden

Die Regel „Wenn du keine Rechnungen damit machst, ist es keine Zahl“ gilt für viele IDs in russischen und globalen Systemen. Wichtige Beispiele:

• SNILS (11 Ziffern, Format XXX-XXX-XXX XX): Als VARCHAR(14) oder CHAR(11) nach Entfernen der Bindestriche speichern, nicht als BIGINT.
• Persönliche Steuernummer (INN) (12 Ziffern): Kann mit Null für Regionen 01–09 beginnen, daher VARCHAR(12) zwingend.
• Telefonnummer: Nur VARCHAR(20), um das '+' für internationale Formate zu behalten.
• Postleitzahl: CHAR(6), da internationale alphanumerisch sein können.
• Bankkonto (20 Ziffern): CHAR(20), da numerische Typen diese Länge ohne Überlauf nicht packen.

String-Typen gewährleisten Flexibilität und verhindern Datenverluste durch Formatänderungen.

Wichtige Erkenntnisse

• Semantik zuerst: Datentyp basierend auf Operationen wählen, nicht auf Optik.
• Führende Nullen zählen: Numeriker entfernen sie und zerstören IDs bei Millionen Datensätzen.
• Optimierung sekundär: Keine Byteersparnis oder Mikrosekunden gegen schlechte Daten eintauschen.
• Universelles Prinzip: Gilt für SNILS, INN, Telefonnummern und mehr.
• Eure Schemas prüfen: Bestehende Datenbanken auf versteckte Risiken durchchecken.

Wie wählt man den richtigen Datentyp?

Ein solider Entwickler stellt sich bei der Gestaltung eines Datenbankfelds drei Fragen:

• Welche Semantik? (ID, Menge, Text?)
• Welche Operationen? (Vergleichen, Suchen, Rechnen?)
• Welche Geschäftsregeln? (Format, Länge, Zeichen?)

Die Antworten bestimmen die Wahl: Strings für IDs, Numeriker für Mengen. Das trennt Problemlösung von Copy-Paste-Coding und erstickt teure Bugs im Keim.

Datentypen für russische IDs

| Daten | Format | Richtiger Typ | Häufiger Fehler | Fehlerfolge |

|---------------|------------|---------------|-----------------|------------------------------|

| Passserie | 4 Ziffern | CHAR(4) | INTEGER | Verlust führender Null, ungültiges Dokument |

| Passnummer | 6 Ziffern | CHAR(6) | INTEGER | Null gekürzt, ID kaputt |

| Voller Pass | 10 Ziffern| CHAR(10) | BIGINT | Bis zu zwei führende Nullen weg |

| SNILS | 11 Ziffern| CHAR(11) | BIGINT | Kürzung bei 01–09-Codes |

| Pers. INN | 12 Ziffern| CHAR(12) | BIGINT | Ziffernverlust bei 01–09 |

| Telefon | +7... | VARCHAR(20) | BIGINT | Kein '+', keine Intl-Unterstützung |

| PLZ | 6 Ziffern | CHAR(6) | INTEGER | Keine alphanumer. Intl-Codes|

| Bankkonto | 20 Ziffern| CHAR(20) | Kein passender INT | Überlauf, Finanzrisiken |

Diese Tabelle ist euer Spickzettel für Schemadesign und Audits.

— Editorial Team