Antwoord.

Geschiedenis van de vraag

Wijziging van het tabelschema is relevant geworden met de massale verspreiding van Agile-methodologieën. Projecten evolueren, eisen veranderen — na verloop van tijd ontstaat er vaak de noodzaak om kolommen toe te voegen/wijzigen/verwijderen. Dergelijke wijzigingen zijn bijzonder riskant in actieve productiedatabases.

Probleem

De wijziging van de structuur kan leiden tot:

langdurige vergrendelingen
verlies of onjuiste migratie van oude gegevens
schending van externe beperkingen, triggers of applicatielogica

Veranderingen in grote tabellen (miljoenen rijen) die actief door andere services worden gebruikt, zijn bijzonder complex.

Oplossing

Slim omgaan met ALTER TABLE — gefaseerde wijzigingen, het maken van een kopie van gegevens, testen op een testomgeving, beperken van de downtime. Het gebruik van transacties, gefaseerde migratie en back-ups voor grote wijzigingen. In hoogbelaste DBMS worden vaak "online"-algoritmen voor ALTER gebruikt.

Voorbeeldcode:

-- Een nieuwe kolom toevoegen met een standaardwaarde
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- Geleidelijk vullen van nieuwe kolommen
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

Belangrijke kenmerken:

Het is wenselijk om eerst nieuwe kolommen te maken en daarna geleidelijk gegevens over te zetten
Grote operaties moeten buiten piekuren worden uitgevoerd
Altijd back-ups maken en automatiseringstests uitvoeren

Misleidende vragen.

Wordt ALTER TABLE atomair uitgevoerd?

Meestal niet: het wijzigen van een tabel kan veel tijd in beslag nemen. In geval van een storing kan een deel van de wijzigingen worden teruggedraaid, maar een deel kan blijven hangen. Daarom wordt transactionele bescherming op DDL-commando's slechts door enkele DBMS geïmplementeerd (bijvoorbeeld PostgreSQL).

Is het pijnloos om het type van een kolom te veranderen van INTEGER naar VARCHAR?

Niet altijd: als er oude gegevens in de kolom zijn die niet overeenkomen met het nieuwe formaat, of gerelateerde objecten (indexen, triggers, sleutels), kan de DBMS weigeren het type te wijzigen of kunnen de gegevens beschadigd raken.

Legt ALTER TABLE altijd een exclusieve vergrendeling op de hele tabel?

Het hangt af van de DBMS: in MySQL en oudere versies van SQL Server blokkeert elke ALTER-bewerking vaak de hele tabel totdat deze is voltooid, maar moderne DBMS ondersteunen "online DDL", waardoor de vergrendeltijd wordt verminderd.

Typische fouten en anti-patronen

Wijziging van de structuur zonder back-up
Migratie van grote tabellen zonder test op de testomgeving
Het hernoemen van kolommen zonder afhankelijkheden (bijvoorbeeld, externe sleutels, procedures) te controleren
Massale ALTER in piekuren

Voorbeeld uit het leven

Negatieve casus

Een DevOps-engineer voerde massale wijzigingen door in drie belangrijke tabellen via ALTER TABLE en verwijderde oude kolommen. Hij hield er geen rekening mee dat deze kolommen gekoppelde externe sleutels en triggers hadden. Tijdens het uitvoeren van ALTER was de database 20 minuten in gebruik — in die tijd "vielen" de services uit door het ontbreken van de benodigde velden.

Voordelen:

Wijzigingen werden uitgevoerd volgens de specificaties

Nadelen:

Verlies van functionaliteit van sommige services
Downtime van bijna een half uur voor het bedrijf
Tijdrovend herstel van afhankelijkheden en terugzetten van verwijderde gegevens

Positieve casus

Een analist plande de toevoeging van een kolom in verschillende fasen: eerst werd een kolom met een standaard ingesteld, waarna testbelasting op de kopieën werd uitgevoerd, en pas daarna vond de echte ALTER 's nachts plaats waarbij alle ontwikkelaars werden geïnformeerd over het aanstaande migratiewindow.