Namensgenerator für Datenbanktabellen

Die Tabelle vor den Spalten lesen

Ein Tabellenname wird überall wiederholt, wo Daten verarbeitet werden: im Anwendungscode, in SQL, Migrationen, Dashboards, Störungsmeldungen und Teamgesprächen. Deshalb ist die Benennung eine Architekturentscheidung. CustomerContactDetails sollte Datensätze direkt beschreiben. UserRoleAssignments macht die Beziehung selbst sichtbar. SchemaMigrationLocks signalisiert dagegen, dass die Tabelle Arbeit koordiniert und kein Fachobjekt repräsentiert.

Name und Datenlebenszyklus verbinden

Der Lebenszyklus liefert oft die wichtigste Ergänzung. PaymentEvents spricht für eine nur wachsende Historie. DailySalesRollups bezeichnet abgeleitete Summen. StagedCustomers weist auf importierte Datensätze vor der Freigabe hin. ArchivedCustomerRecords warnt vor inaktiven Einträgen. CacheInvalidationEvents betrifft die Steuerung abgeleiteter Daten, DataErasureRequests verbindet Datenschutz mit einem Arbeitsablauf. Verwende solche Wörter nur, wenn Constraints, Aufbewahrung und Schreibmuster sie bestätigen.

Fachsprache technisch präzise nutzen

Gute Namen verbinden Produktvokabular und Datenbankstruktur. Nutze Begriffe, die Support, Finanzen, Betrieb und Analyse kennen, und ergänze technische Qualifikationen nur bei echter Mehrdeutigkeit. InvoicePaymentAllocations ist sinnvoll, wenn Verteilung ein eigener Vorgang ist. CountryCodes genügt für einen schlanken Katalog. TenantNotificationRules passt, wenn jede Zeile eindeutig zu einem Mandanten gehört. Vermeide Versionsnummern oder Servicenamen, die verschwinden, während die Daten bleiben.

Kurzer Namenscheck

• Zentrale Entität oder zentrales Ereignis zuerst nennen.
• Logs, Events, Audits und History für tatsächlich verschiedene Lebenszyklen reservieren.
• Join-Tabellen im ganzen Schema nach derselben Logik benennen.
• Staged, Cached, Archived oder Rollup nur bei wahrer betrieblicher Bedeutung verwenden.
• Stabile Fachbegriffe flüchtigen Implementierungsnamen vorziehen.

Fragen vor der nächsten Migration

Prüfe einen Vorschlag in einem JOIN, einem Migrationstitel und einem Alarm. Kläre, wem die Daten gehören, ob aktueller Zustand oder Verlauf gespeichert wird und ob eine Nachbartabelle denselben Begriff beansprucht. Wähle dann den kürzesten Namen, der diese Unterschiede bewahrt.

• Was würde der Bereitschaftsdienst allein aus dem Namen schließen?
• Welches Wort trennt die Tabelle von ihrer nächsten Nachbarin?
• Funktioniert der Name noch nach dem Austausch der aktuellen Funktion?
• Welchen Constraint oder Lebenszyklus sollte der Name leise signalisieren?