Eine Tabelle ohne Big Bang aufteilen: Aus einem Datenmodell werden zwei

2026-10-28 · 2 Min.

Nehmen wir an, dass die Tabelle Customer im Laufe der Jahre auf mehrere Dutzend Spalten angewachsen ist.

Einen Teil der Adressdaten möchten wir in eine eigene Tabelle auslagern.

Die neue Tabelle

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
CREATE TABLE dbo.CustomerAddress
(
    CustomerId int NOT NULL,
    AddressType varchar(20) NOT NULL,
    AddressLine1 nvarchar(200) NOT NULL,
    City nvarchar(100) NOT NULL,
    PostalCode nvarchar(20) NULL,
    CONSTRAINT PK_CustomerAddress
        PRIMARY KEY (CustomerId, AddressType)
);

Schritt 1 — Die neue Struktur ergänzen, ohne die alte zu entfernen

Die bisherigen Spalten bleiben bestehen. Die neue Tabelle erweitert zunächst das Datenmodell.

Schritt 2 — Bestehende Daten übernehmen (Backfill)

1
2
3
4
5
6
7
8
INSERT dbo.CustomerAddress
(
    CustomerId, AddressType, AddressLine1, City, PostalCode
)
SELECT
    CustomerId, 'PRIMARY', AddressLine1, City, PostalCode
FROM dbo.Customer
WHERE AddressLine1 IS NOT NULL;

Bei großen Tabellen führen wir die Übernahme in Batches durch und speichern den Fortschritt mithilfe von Checkpoints.

Schritt 3 — Beide Modelle synchron halten

Während der Übergangsphase muss eine Adressänderung entweder in beiden Modellen ankommen oder in einer führenden Datenquelle erfolgen, von der aus das andere Modell synchronisiert wird.

Schritt 4 — Lesezugriffe umstellen

Zunächst leiten wir nur einen kleinen Teil der Zugriffe auf das neue Modell und erhöhen den Anteil schrittweise.

Mit Shadow Reads lassen sich die Ergebnisse der alten und der neuen Darstellung vergleichen.

Schritt 5 — Die alten Spalten entfernen

Das ist der letzte Schritt und gehört nicht zum ersten Deployment.

Vor der Contract-Phase prüfen wir:

  • Berichte,
  • Integrationen,
  • ETL-Prozesse,
  • gespeicherte Prozeduren,
  • dynamisches SQL,
  • Exporte,
  • BI-Werkzeuge.

Semantische Risiken

Die Aufteilung einer Tabelle verändert häufig nicht nur das physische Schema, sondern auch die Bedeutung der Daten.

Aus einer Adresse können mehrere Adressen werden. In diesem Fall kann ein Rollback auf das alte Modell mit Informationsverlust verbunden sein.

Fazit

Eine Tabellenaufteilung ist dann am sichersten, wenn wir zuerst die neue Darstellung ergänzen, anschließend die Zugriffe umstellen und erst ganz am Ende die alte Struktur entfernen.


Tags: SQL Server , Schema-Evolution , Normalisierung , Datenmigration , Database DevOps

Marcin Pytlik
LinkedIn · GitHub

Marcin Pytlik

LinkedIn · GitHub