SQL CREATE TABLE: tabellen maken en gegevens wijzigen

Een tabeldefinitie beschrijft wat elke rij kan bevatten. Ze voegt geen rijen toe. In een webwinkel heeft elk product afzonderlijke velden nodig voor de identificatiewaarde, naam, prijs en voorraad.

Stel de definitie op

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL,
  in_stock INTEGER DEFAULT 0
);

Lees van buiten naar binnen. CREATE TABLE products geeft de nieuwe tabel een naam. Tussen haakjes staan de kolomdefinities. Elke regel geeft een kolomnaam, een type en eventuele regels voor die kolom. Komma's scheiden de definities; na de laatste definitie staat geen komma. De puntkomma beëindigt de instructie. Nadat die is geslaagd, geeft SELECT * FROM products; nul rijen terug.

Deze sleuteldeclaratie genereert identificatiewaarden in SQLite. Gebruik in PostgreSQL id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY om ze te genereren. De decimale declaratie gedraagt zich in deze systemen ook verschillend; een exacte opslag kiezen hoort bij de keuze van een type.

Geef elk gegeven een eigen kolom

Een klantrij kan id, first_name, last_name, email en signup_date bevatten. Als je “Ana Ruiz, ana@example.com” in één veld stopt, zijn de naam en het e-mailadres moeilijk afzonderlijk te doorzoeken of te controleren. Geef de velden namen die aangeven wat ze bevatten. Korte namen in kleine letters, verbonden met lage streepjes, zoals unit_price, zijn gemakkelijk opnieuw te gebruiken.

Gebruik geen trefwoorden als naam: orders werkt, terwijl order zonder aanhalingstekens botst met het SQL-trefwoord ORDER. Een naam met spaties heeft dubbele aanhalingstekens nodig, zoals in "order date", telkens wanneer je die gebruikt. PostgreSQL zet namen zonder aanhalingstekens om naar kleine letters, dus Products en products zonder aanhalingstekens verwijzen naar dezelfde naam.

Enkele aanhalingstekens hebben een andere functie: ze sluiten tekstwaarden zoals 'Desk lamp' in. Dubbele aanhalingstekens duiden namen aan. PostgreSQL leest "Desk lamp" als kolomnaam, niet als producttekst.

Controleer wat is aangemaakt

Een afsluitende komma vóór ) veroorzaakt een syntaxisfout. Een ontbrekende komma doet dat vaak ook, maar SQLite kan meerdere woorden als één typenaam lezen. CREATE TABLE t (a INTEGER b TEXT); maakt één kolom met de naam a, geen twee kolommen. Bekijk de definitie:

• SQLite-shell: .schema products toont de aanmaakinstructie.
• SQLite-SQL: PRAGMA table_info(products); geeft een lijst van kolommen en typen.
• PostgreSQL-psql: \d products toont kolommen, typen en integriteitsregels.

CREATE TABLE IF NOT EXISTS products (...) voorkomt een fout als de naam al bestaat. De oude definitie wordt niet vergeleken of bijgewerkt. Een tabel waarin een benodigde kolom ontbreekt, blijft zo.

Maak een eenmalige kopie

CREATE TABLE cheap_products AS
SELECT name, price FROM products WHERE price < 10;

Dit maakt kolommen en kopieert de rijen van de query. Latere productwijzigingen werken de kopie niet bij. In SQLite en PostgreSQL erft de nieuwe tabel de primaire sleutel en de NOT NULL- en CHECK-regels van de bron niet.

CREATE, ALTER en DROP behoren tot de gegevensdefinitietaal, ofwel DDL: ze wijzigen de structuur. INSERT, UPDATE en DELETE zijn gegevensmanipulatietaal, ofwel DML: ze wijzigen rijen. SELECT leest gegevens; boeken verschillen van mening of dit bij DML hoort of dat query's een eigen familie vormen.

Kies een type op basis van wat je met de waarde moet doen. Een hoeveelheid moet geschikt zijn voor berekeningen. Een Amerikaanse postcode moet zijn tekens behouden, inclusief voorloopnullen. Beide kunnen uit cijfers bestaan, maar hebben een andere opslag nodig.

Kies typen voor getallen en tekst

In PostgreSQL heeft NUMERIC(8, 2) in totaal acht cijfers, waarvan twee na de decimale komma. De grootste positieve waarde is 999.999,99. Als je 12,345 invoegt, wordt 12,35 opgeslagen; 1.234.567,00 veroorzaakt een overloop omdat er zeven cijfers vóór de komma nodig zijn. DECIMAL is een andere naam voor deze typenfamilie.

SQLite accepteert NUMERIC(8, 2), maar dwingt die precisie of schaal niet af. Het slaat 19,99 op als drijvendekommagetal en behoudt 12,345 zonder afronding. Sla 1999 gehele centen op voor een exact bedrag van 19,99. Drijvendekommagetallen kunnen decimale waarden als binaire benaderingen opslaan: SELECT 0.1 + 0.2 = 0.3; van SQLite geeft 0 terug. PostgreSQL behandelt deze losse decimale literals als exacte numerieke waarden; converteer ze naar DOUBLE PRECISION om het benaderde resultaat te zien.

Getallen als tekst worden op tekens gesorteerd: '100', '25', '9' verschijnen in die volgorde. Numerieke hoeveelheden hebben numerieke kolommen nodig. De Amerikaanse postcode '02139' hoort in tekst; bij opslag als geheel getal gaat de voorloopnul verloren.

VARCHAR(20) van PostgreSQL weigert tekst die langer is dan 20 tekens. CHAR(n) vult kortere tekst met spaties aan tot een vaste lengte. TEXT heeft geen gedeclareerde tekenlimiet. SQLite behandelt zowel VARCHAR(n) als CHAR(n) als tekst, zonder de lengte af te dwingen of aan te vullen.

Sla datums en ja/nee-waarden op

PostgreSQL heeft DATE, TIME, TIMESTAMP en BOOLEAN. Het weigert een onmogelijke DATE zoals '2026-02-30'. SQLite heeft geen afzonderlijk opslagtype voor datums. Gebruik ISO-tekst zoals '2026-03-15', waarvan de tekenvolgorde overeenkomt met de datumvolgorde. Tekst in Amerikaanse notatie sorteert datums uit verschillende jaren verkeerd: '12/01/2025' komt na '03/15/2026'.

Een tijdstempel voegt een tijd toe, zoals in '2026-03-15 14:30:00'. PostgreSQL gebruikt TRUE en FALSE voor Booleaanse waarden; SQLite slaat 1 en 0 op en accepteert die trefwoorden. MySQL behandelt BOOLEAN als een klein geheel getal; SQL Server gebruikt BIT.

Weet wat het systeem afdwingt

Gewone SQLite-tabellen gebruiken typeaffiniteit, een opslagvoorkeur. Een INTEGER-kolom zet '5' om naar 5, maar accepteert 'abc' als tekst. PostgreSQL weigert tekst die geen geheel getal kan worden. SQLite 3.37.0 en later ondersteunen STRICT-tabellen, waarvan de toegestane typen INT, INTEGER, REAL, TEXT, BLOB en ANY zijn.

Kies voor orders een gehele id, een e-mailadres als tekst, een PostgreSQL-DATE of SQLite-datum als ISO-tekst, PostgreSQL-NUMERIC(10, 2) of gehele centen in SQLite voor het totaal, en een Booleaanse waarde of 0/1-indicator voor de betaling. NULL betekent ontbrekend of onbekend; het is geen type en is niet hetzelfde als nul of een lege tekenreeks. Een kolom accepteert het tenzij een regel dat verbiedt.

Een integriteitsregel laat de database gegevens weigeren die een gedeclareerde regel schenden. De controle wordt uitgevoerd wanneer rijen worden ingevoegd of bijgewerkt, ongeacht welke applicatie de instructie verstuurt. Verschillende regels beschermen verschillende onderdelen van een productrecord.

Combineer regels in een tabel

Deze SQLite-definitie genereert de sleutel en controleert de andere velden. Vervang voor PostgreSQL de sleutelregel door een primaire sleutel met identiteit.

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  sku TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL CHECK (price > 0),
  in_stock INTEGER NOT NULL DEFAULT 0 CHECK (in_stock >= 0)
);

NOT NULL vereist een waarde. UNIQUE voorkomt een herhaalde SKU. CHECK (price > 0) weigert prijzen van nul of lager. De voorraad heeft een standaardwaarde van 0 en mag niet negatief worden. De numerieke declaratie van SQLite zorgt niet voor exact decimaal rekenen, dus gebruik gehele centen wanneer exactheid van belang is.

Maak onderscheid tussen weglaten en NULL

Voeg een bureaulamp in met SKU 'LAMP-01', naam 'Desk lamp' en prijs 24,99, en laat de voorraad uit de kolommenlijst weg. De invoeging slaagt en de voorraad wordt 0. Met een opgegeven voorraad van NULL vraag je niet om de standaardwaarde: die voldoet niet aan NOT NULL.

Een koffiemok met een prijs van -3,50 voldoet niet aan de prijscontrole. Een tweede product met SKU 'LAMP-01' voldoet niet aan UNIQUE, ook als de naam en prijs verschillen. Een pen zonder naam voldoet niet aan NOT NULL. Lees welke regel of kolom in de foutmelding wordt genoemd en corrigeer de invoer.

Lege tekst is een echte waarde. name TEXT NOT NULL accepteert '' in SQLite en PostgreSQL. Voeg CHECK (name <> '') toe om die te weigeren. Oracle behandelt lege tekst als NULL, dus daar valt dezelfde invoer onder een andere regel.

Controleer combinaties en ontbrekende waarden

Een kolomregel volgt op het type. Een tabelregel is een afzonderlijk onderdeel binnen de tabeldefinitie en kan kolommen vergelijken:

CHECK (end_date >= start_date),
UNIQUE (order_id, product_id)

De eerste weigert een einddatum vóór een begindatum. De tweede weigert een herhaald paar: een product kan in verschillende orders voorkomen, maar niet tweemaal in dezelfde order. Een tabel kan meerdere uniekheidsregels hebben.

Een controle weigert een rij als de voorwaarde onwaar is. Als de prijs NULL is, is price > 0 onbekend en komt de rij dus door de controle. Daarom heeft de productprijs ook NOT NULL nodig. PostgreSQL, SQLite en MySQL staan normaal gesproken meerdere NULL-waarden toe onder UNIQUE; SQL Server staat er één toe bij een uniekheidsregel voor één kolom. PostgreSQL 15 en later bieden UNIQUE NULLS NOT DISTINCT als ook ontbrekende waarden met elkaar moeten botsen. MySQL-versies vóór 8.0.16 negeerden CHECK-regels.

Geef een regel een bruikbare naam met CONSTRAINT price_positive CHECK (price > 0). De naam helpt om de regel in een foutmelding te herkennen en later te verwijderen. Een integriteitsregel controleert precies de eigen expressie: CHECK (email LIKE '%@%') vangt een ontbrekend apenstaartje op, maar geen typefout in een adres dat verder aan het patroon voldoet.

Een primaire sleutel identificeert een rij op betrouwbare wijze. Dat kan één kolom of een combinatie zijn, maar een tabel heeft maximaal één primaire sleutel. De sleutel moet uniek en aanwezig zijn, zodat andere instructies een rij kunnen aanduiden zonder afhankelijk te zijn van de beschrijving ervan.

Kies een stabiele identificatiewaarde

Een natuurlijke sleutel is een bestaande identificatiewaarde uit de praktijk, zoals het ISBN van een boek. Een surrogaatsleutel is een kunstmatige identificatiewaarde, vaak een gegenereerd geheel getal. Het e-mailadres van een klant kan veranderen; een gegenereerde klantidentificatie kan daarbij gelijk blijven.

Een samengestelde sleutel identificeert een combinatie:

PRIMARY KEY (order_id, product_id)

Een order kan meerdere producten bevatten en een product kan in meerdere orders voorkomen. Het paar identificeert één orderregel. Geen van beide kolommen hoeft afzonderlijk uniek te zijn.

PostgreSQL, MySQL en SQL Server dwingen af dat primaire sleutels aanwezig zijn. Gewone SQLite-tabellen behouden een historische uitzondering: een primaire sleutel die geen INTEGER PRIMARY KEY is, kan NULL bevatten. Gebruik code TEXT PRIMARY KEY NOT NULL voor een tekstsleutel. SQLite-STRICT-tabellen sluiten deze uitzondering ook uit.

Laat de database het nummer genereren

Laat id weg uit de kolommenlijst van de invoeging om een gegenereerde waarde te vragen. Een gewone PostgreSQL-INTEGER PRIMARY KEY genereert die niet. Oudere PostgreSQL-code gebruikt vaak SERIAL.

In SQLite is INTEGER PRIMARY KEY een alias voor het interne rijnummer. Begin met de gegenereerde identificatiewaarden 1, 2 en 3 en verwijder daarna 3. De volgende normaal gegenereerde identificatiewaarde is opnieuw 3, één boven het huidige maximum. Met INTEGER PRIMARY KEY AUTOINCREMENT is dat 4: een nummer dat een vastgelegde rij heeft gehad, wordt niet hergebruikt. Een nummer van een teruggedraaide invoeging kan nog wel worden hergebruikt. Deze sterkere garantie kost extra werk, dus kies ervoor als niet-hergebruiken een belangrijke eis is.

Lees identificatiewaarden zonder ze als aantallen te behandelen

Gaten zijn normaal. Verwijderingen laten ze achter en PostgreSQL geeft volgnummers na mislukte of teruggedraaide invoegingen niet opnieuw uit. Gebruik COUNT(*) voor een aantal rijen en een tijdstempel voor het tijdstip van een gebeurtenis. De grootste identificatiewaarde beantwoordt geen van beide vragen betrouwbaar.

De vorm GENERATED ALWAYS van PostgreSQL weigert normaal gesproken een expliciete identificatiewaarde zoals 50. GENERATED BY DEFAULT en SERIAL accepteren expliciete waarden, maar als je 50 opgeeft, gaat de generator daardoor niet voorbij 50. Een later gegenereerde waarde kan ermee botsen.

Lees de sleutel terug om die van een nieuwe rij in een gerelateerde rij te gebruiken:

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

RETURNING werkt in PostgreSQL en SQLite 3.35.0 en later. SQLite biedt ook last_insert_rowid(), MySQL biedt LAST_INSERT_ID() en SQL Server gebruikt OUTPUT. Lees het resultaat van de invoeging in plaats van de volgende identificatiewaarde te raden.

De customer_id van een order moet verwijzen naar een klant die bestaat. Een refererende sleutel laat de database die koppeling controleren. De tabel met de verwijzing is de kindtabel; de tabel waarnaar wordt verwezen is de oudertabel.

Declareer en handhaaf de koppeling

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers(id)
);

Hier moet customers eerst bestaan en moet de id daarvan een primaire of unieke sleutel zijn. Zorg dat de typen aan beide kanten overeenkomen. De tabelvorm, FOREIGN KEY (customer_id) REFERENCES customers(id), declareert dezelfde koppeling los van de kolom.

Als handhaving is ingeschakeld, mislukt een order voor klant 99 wanneer klant 99 niet bestaat. Een order wijzigen naar die ontbrekende klant mislukt ook. Een refererende sleutel die NULL toestaat, kan NULL bevatten, wat betekent dat er geen gekoppelde rij is; NOT NULL maakt de koppeling verplicht.

Voer in SQLite PRAGMA foreign_keys = ON; uit op elke nieuwe verbinding voordat je een transactie start. Een wijziging van de instelling binnen een transactie heeft geen effect. PostgreSQL en SQL Server handhaven refererende sleutels normaal gesproken, en de standaardengine InnoDB van MySQL doet dat ook.

Voorspel wat er gebeurt als een ouder wordt verwijderd

Gebruik klanten 1, Ana, en 2, Ben. Orders 101 en 102 horen bij Ana; 103 hoort bij Ben. Bekijk wat er gebeurt als klant 1 onder verschillende declaraties wordt verwijderd:

SET NULL heeft een kolom nodig die NULL toestaat. Ook SET DEFAULT moet aan de refererende sleutel voldoen: een standaardwaarde die niet ontbreekt, moet een bestaande ouder identificeren. Een standaardwaarde NULL werkt wanneer ontbrekende koppelingen zijn toegestaan.

Kies op basis van de betekenis van de gegevens. Orderregels horen vaak volledig bij hun order, dus cascadering kan passen. Voor orders die bewaard moeten blijven, is een blokkerende actie nodig als iemand hun klant probeert te verwijderen. Een optionele leverancierskoppeling kan op NULL worden gezet. Als je overal cascadering toepast, kan één verwijdering meer records verwijderen dan de tabelnaam doet vermoeden.

Werk in volgorde van afhankelijkheid

Maak ouders vóór kinderen en voeg ouderr ijen in vóór rijen die ernaar verwijzen. Werk bij het verwijderen van gerelateerde gegevens of tabellen van kinderen naar ouders. Een ON UPDATE-actie biedt dezelfde keuzes wanneer de sleutel van de ouder verandert; ON UPDATE CASCADE kopieert de nieuwe sleutel naar de kinderen.

RESTRICT controleert direct. NO ACTION, de standaardwaarde, kan wachten tot het einde van de instructie, of tot het einde van de transactie bij een uitstelbare integriteitsregel. Beide blokkeren een gewone verwijdering die verwijzingen zonder overeenkomst zou achterlaten. Houd gegenereerde identificatiewaarden stabiel, zodat je niet elke verwijzing naar een klant hoeft te wijzigen als diens gegevens veranderen.

INSERT voegt rijen toe aan een bestaande tabel. De kolommenlijst bepaalt hoe de opgegeven waarden worden gekoppeld aan de velden die ze ontvangen. Schrijf die lijst expliciet, zodat een latere tabelwijziging de betekenis van je invoer niet ongemerkt verandert.

Koppel waarden op volgorde

INSERT INTO products (sku, name, price, in_stock)
VALUES ('LAMP-01', 'Desk lamp', 24.99, 12);

Lees de paren op volgorde: SKU krijgt 'LAMP-01', naam krijgt 'Desk lamp', prijs krijgt 24,99 en voorraad krijgt 12. Voor deze vier kolommen moeten er vier waarden zijn. Een verschil, zoals twee waarden voor drie kolommen, leidt tot een fout.

Zonder de lijst volgen de waarden de gedeclareerde kolomvolgorde van de tabel. SQLite vereist dat alle kolommen een waarde krijgen; PostgreSQL staat minder waarden toe en geeft de resterende kolommen aan het einde hun standaardwaarde. Met een expliciete lijst hoef je niet op een van beide werkwijzen te vertrouwen. Je kunt de kolommen ook in een volgorde zetten die duidelijk is voor de invoer.

Een verwisseld paar kan erger zijn dan een syntaxisfout. Als je 9,99 als naam en 'Desk lamp' als prijs opgeeft, weigert PostgreSQL de niet-numerieke prijs. De gewone affiniteit van SQLite kan de naamtekst “9.99” en prijstekst “Desk lamp” zonder fout opslaan. Lees de ingevoegde rij terug met SELECT om de koppeling te controleren.

Schrijf literals correct

De dubbele apostrof slaat één apostrof op. Getallen hebben geen valutateken of scheidingsteken voor duizendtallen; een komma scheidt waarden, dus een komma binnen een bedrag zonder aanhalingstekens verandert het aantal waarden. 'NULL' is de tekst “NULL” van vier letters, geen ontbrekende waarde.

Laat weggelaten velden zichzelf vullen

Een weggelaten kolom krijgt de standaardwaarde, of NULL als er geen standaardwaarde is. Een gegenereerde sleutel krijgt een gegenereerde waarde. Dat laatste gedrag hangt af van de declaratie: INTEGER PRIMARY KEY van SQLite genereert identificatiewaarden; PostgreSQL heeft daarvoor een identiteitsdeclaratie nodig. Een gewone primaire sleutel met een geheel getal in PostgreSQL die uit een invoeging wordt weggelaten, leidt tot een fout omdat de waarde NULL zou zijn.

PostgreSQL, MySQL en SQL Server staan DEFAULT toe als plaatsaanduiding voor een waarde. SQLite accepteert dit niet binnen een VALUES-lijst; laat die kolom daar weg. Een expliciete NULL vraagt nooit om de standaardwaarde.

Voeg meerdere rijen tegelijk toe

INSERT INTO customers (first_name, last_name, email) VALUES
  ('Ana', 'Ruiz', 'ana@example.com'),
  ('Ben', 'Okafor', 'ben@example.com'),
  ('Chloe', 'Nguyen', 'chloe@example.com');

In een lege tabel waarvan de gegenereerde sleutel bij 1 begint, krijgen deze klanten de identificatiewaarden 1, 2 en 3. Bij de gewone afhandeling van integriteitsregels slaagt of mislukt de instructie voor meerdere rijen als geheel. Als één rij een regel schendt, wordt geen van de rijen van deze instructie ingevoegd.

Een UNIQUE-fout wijst op een dubbele sleutel of waarde; NOT NULL wijst op ontbrekende gegevens; CHECK wijst op een voorwaarde waaraan niet is voldaan; en een refererende-sleutelfout wijst op een ongeldige koppeling. Corrigeer de waarde of de bedoelde koppeling voordat je het opnieuw probeert.

Je hoeft rijen niet één voor één in te typen. Een query kan de rijen voor een invoeging leveren en een conflictregel kan aangeven wat er moet gebeuren als een unieke waarde al bestaat. Bij beide functies is het belangrijk dat de gegevens precies overeenkomen met wat je bedoelt.

Kopieer een queryresultaat

INSERT INTO archived_orders (id, customer_id, order_date, total)
SELECT id, customer_id, order_date, total
FROM orders
WHERE order_date < '2026-01-01';

Er is geen VALUES-clausule: de query levert de waarden. Koppel de geselecteerde kolommen op volgorde aan de doellijst. De doeltabel moet al bestaan en de bijbehorende regels blijven gelden.

Bekijk de SELECT eerst afzonderlijk. Orders 201, 202 en 204 hebben de datums 2025-11-03, 2025-12-19 en 2025-10-30 en de bedragen 45,00, 120,50 en 60,00. Orders 203 en 205 zijn uit 2026. De query geeft drie rijen terug met een totaal van 225,50 en de invoeging kopieert die drie. Er kunnen ook nul rijen worden gekopieerd als het filter niets vindt.

Een tweede uitvoering probeert ze opnieuw te kopiëren. Een primaire sleutel in de doeltabel laat dat mislukken in plaats van ongemerkt dubbele gegevens op te slaan. INSERT ... SELECT is een kopieerbewerking; de bronrijen worden niet verwijderd en de twee tabellen worden niet gesynchroniseerd.

Bestanden worden vaak eerst in een stagingtabel geïmporteerd. De shell van SQLite gebruikt .import --csv file.csv staging; psql gebruikt \copy. In een latere query verwijdert TRIM(email) spaties aan het begin en einde en zet NULLIF(TRIM(email), '') een leeg e-mailadres om in NULL. De integriteitsregels van de doeltabel controleren vervolgens de opgeschoonde rijen.

Lees het resultaat van een schrijfbewerking

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

Het resultaat geeft de gegenereerde klantidentificatie terug voor gebruik in een gerelateerde rij. PostgreSQL en SQLite 3.35.0 en later ondersteunen RETURNING bij invoegen, bijwerken en verwijderen. MySQL gebruikt LAST_INSERT_ID() voor een gegenereerde identificatiewaarde; SQL Server gebruikt OUTPUT.

Bepaal hoe dubbele waarden worden verwerkt

Stel dat bij stock (sku TEXT PRIMARY KEY, qty INTEGER NOT NULL) de hoeveelheid van 'LAMP-01' 12 is. Een gewone invoeging met dezelfde SKU en hoeveelheid 20 mislukt. In SQLite en PostgreSQL:

INSERT INTO stock (sku, qty) VALUES ('LAMP-01', 20)
ON CONFLICT (sku) DO UPDATE
SET qty = stock.qty + excluded.qty;

stock.qty is de bestaande 12. excluded.qty is de voorgestelde 20. Deze vorm slaat 32 op, wat past bij een extra levering. SET qty = excluded.qty slaat 20 op, wat past bij een vervangende voorraadstand. DO NOTHING behoudt 12 en slaat de conflicterende rij over. Elke variant gaat uit van dezelfde oorspronkelijke hoeveelheid 12.

Een upsert combineert het invoegen van een nieuwe rij met bijwerken bij een conflict. Het conflictdoel moet een geschikte uniekheidsregel hebben. De overeenkomstige instructiefamilie in MySQL is ON DUPLICATE KEY UPDATE. Een gewone INSERT corrigeert geen bestaande klant: er ontstaat een extra rij of een uniekheidsfout. Gebruik UPDATE voor een rij waarvan je weet dat die bestaat, en een upsert als de rij mogelijk al bestaat.

UPDATE wijzigt waarden in bestaande rijen. De instructie noemt een tabel, wijst met SET nieuwe waarden toe en kiest vervolgens met WHERE de doelrijen. De integriteitsregels van de tabel controleren de resulterende waarden.

Stel één of meer velden in

UPDATE products
SET price = 22.50, in_stock = 30
WHERE id = 3;

Het product met sleutel 3 krijgt beide waarden; andere rijen behouden hun waarden. Tussen toewijzingen staan komma's. SET price = 22.50 AND in_stock = 30 betekent geen twee toewijzingen. PostgreSQL weigert dit; SQLite behandelt de rechterkant als een Booleaanse expressie en kan 0 of 1 opslaan in de prijs.

Een ontbrekende WHERE is geldige SQL en de instructie geldt dan voor elke rij. UPDATE products SET price = 0; zet de prijs van elk product op nul als de regels van de tabel dat toestaan. Als je vooraf met de bedoelde voorwaarde kijkt, zie je of het doel één rij, meerdere rijen of geen rijen omvat.

Bereken op basis van de opgeslagen waarde

UPDATE products
SET price = price * 1.10;

Een prijs van 20,00 wordt 22,00 na een verhoging van 10%. Een prijs van 19,99 geeft een niet-afgerond resultaat van 21,989. PostgreSQL slaat 21,99 op in een kolom van het type NUMERIC(8, 2). SQLite dwingt de schaal niet af, dus vraagt SET price = ROUND(price * 1.10, 2) om twee decimalen. Bewaar voor exacte opslag van geld in SQLite gehele centen en maak de keuze voor afronding op centen expliciet.

Bij een relatieve wijziging moet de expressie de oude waarde bevatten. SET in_stock = in_stock - 1 haalt één eenheid weg; SET in_stock = 1 vervangt het aantal door één.

In SQLite en PostgreSQL lezen alle expressies rechts van de toewijzing de rij zoals die vóór de wijziging was. UPDATE t SET a = b, b = a; verwisselt de waarden van een rij van 1 en 2 naar 2 en 1. Een wijziging op één tabel in MySQL evalueert toewijzingen van links naar rechts, zodat dezelfde vorm beide waarden 2 maakt. Ga er niet van uit dat dit in alle systemen hetzelfde werkt.

Houd rekening met regels en ontbrekende waarden

Gebruik SET phone = NULL om een telefoonveld leeg te maken. Gebruik WHERE phone IS NULL om ontbrekende telefoonwaarden te vinden. Een gelijkheidsvergelijking met NULL vindt ze niet.

Neem prijzen van 12,00, 3,00 en 8,50 die worden beschermd door CHECK (price > 0). Als je van elke prijs 5 aftrekt, wordt de tweede -2,00. Bij de gewone afhandeling van integriteitsregels draait die fout de hele instructie terug, zodat zelfs de verder geldige prijzen ongewijzigd blijven.

Een wijziging van een primaire sleutel moet ook aan gerelateerde refererende sleutels voldoen. Een geblokkeerde sleutelwijziging mislukt zolang kinderen naar de oude sleutel verwijzen; ON UPDATE CASCADE geeft de nieuwe waarde aan hen door. Door gegenereerde identificatiewaarden stabiel te houden, voorkom je dit extra werk als beschrijvende gegevens veranderen.

Interpreteer het aantal getroffen rijen

psql meldt een resultaat zoals UPDATE 3; changes() van SQLite geeft het aantal voor de laatste wijzigingsinstructie. Beide tellen geselecteerde en bijgewerkte rijen mee, ook als de toegewezen waarde gelijk is aan de oude waarde. Een aantal van drie garandeert geen drie zichtbaar verschillende waarden. Vergelijk het aantal met de selectie vooraf en bekijk daarna de relevante velden, of gebruik RETURNING om getroffen rijen direct te zien.

DELETE verwijdert hele rijen. De tabel blijft bestaan en kan opnieuw rijen bevatten. Gebruik UPDATE ... SET column = NULL om één veld leeg te maken; DELETE email FROM customers is geen geldige SQL.

Volg een gefilterde verwijdering

De winkel heeft deze orders:

DELETE FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Order 201 voldoet aan beide voorwaarden, net als 204. Order 203 is geannuleerd maar te recent; 202 is oud genoeg maar verzonden. De instructie verwijdert twee rijen en laat 202, 203 en 205 staan. DELETE FROM orders; zonder de voorwaarde zou alle vijf verwijderen.

Gebruik gerelateerde gegevens om rijen te kiezen

DELETE FROM order_items
WHERE order_id IN (
  SELECT id FROM orders WHERE status = 'cancelled'
);

De binnenste query levert de identificatiewaarden van geannuleerde orders. IN vergelijkt de order_id van elke orderregel met die lijst. Voer de binnenste query afzonderlijk uit om de sleutels te bekijken en bekijk daarna de orderregels vooraf met dezelfde voorwaarde.

Refererende sleutels beïnvloeden de verwijdering ook. Een ouder met verwijzende kinderen kan worden beschermd door NO ACTION of RESTRICT; cascadering verwijdert kinderen; SET NULL behoudt kinderen maar maakt de koppeling leeg. Controleer die acties wanneer je het effect van het verwijderen van een ouder beoordeelt, want mogelijk verandert meer dan alleen de rechtstreeks genoemde tabel.

Kies wat moet blijven bestaan

PostgreSQL, MySQL, SQL Server en Oracle ondersteunen TRUNCATE; SQLite niet. De regels voor transacties en afhankelijkheden verschillen per database. Ook een instructie die klinkt als een snelle manier om een tabel leeg te maken, moet binnen die regels passen.

Bewaar geschiedenis met een logische verwijdering

UPDATE customers
SET deleted_at = '2026-03-15'
WHERE id = 7;

Een logische verwijdering markeert de rij zonder die te verwijderen. Zo kun je de geschiedenis bewaren en de rij herstellen door de markering te wissen. Query's voor actieve klanten moeten WHERE deleted_at IS NULL bevatten; anders verschijnen de gemarkeerde klanten nog steeds. Gegevens markeren wist ze niet.

Een vastgelegde verwijdering kan niet met een latere ROLLBACK ongedaan worden gemaakt. Herstel vereist een opgeslagen kopie of back-up. Binnen een open transactie kan een terugdraaiing verwijderde rijen nog herstellen. Controleer de geselecteerde identificatiewaarden en het aantal getroffen rijen voordat je het resultaat definitief vastlegt.

Rijen kiezen is vaak het moeilijkste onderdeel van een wijziging. Hetzelfde filter dat in een query onschuldig is, kan te veel verwijderen of bijwerken als je het opnieuw gebruikt bij een schrijfbewerking. Zet de bedoelde regel om in een voorwaarde en bekijk vervolgens wat die daadwerkelijk selecteert.

Bekijk precies dezelfde voorwaarde vooraf

SELECT id, status, order_date FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Deze selectie geeft orders 201 en 204 terug in het winkelvoorbeeld met vijf orders. Gebruik precies die voorwaarde opnieuw bij het verwijderen. Als je die herschrijft terwijl je de opdracht wijzigt, ontstaat een nieuwe, ongecontroleerde selectie.

Gebruik voor één specifieke rij de primaire sleutel: WHERE id = 42 selecteert maximaal één rij. Meerdere producten kunnen dezelfde beschrijvende naam hebben, zoals 'Desk lamp'.

Groepeer alternatieven expliciet

AND bindt sterker dan OR. Vergelijk:

WHERE status = 'cancelled'
   OR status = 'expired' AND order_date < '2026-01-01'

met:

WHERE (status = 'cancelled' OR status = 'expired')
  AND order_date < '2026-01-01'

De eerste accepteert elke geannuleerde order, ongeacht de datum, plus verlopen orders van vóór 2026. Deze selecteert 201, 203 en 204. De tweede past de datumcontrole toe op beide statussen en selecteert 201 en 204. Order 203 laat het verschil zien omdat deze in 2026 is geannuleerd.

Neem ontbrekende waarden bewust mee

WHERE customer_id = NULL selecteert geen rijen. Ontbrekende waarden vereisen IS NULL of IS NOT NULL. Een negatieve test heeft ook een leemte: status <> 'shipped' neemt een ontbrekende status niet mee, omdat de vergelijking onbekend is.

Als een ontbrekende status bij de bedoelde groep hoort, schrijf je:

WHERE status <> 'shipped' OR status IS NULL

Als je nog een voorwaarde toevoegt, groepeer je dit hele alternatief met haakjes zodat beide takken aan die voorwaarde voldoen.

Een patroon kan meer vinden dan de bedoelde beschrijving. LIKE '%lamp%' vindt “Desk lamp” en “Clamp”. De standaardinstelling van LIKE in SQLite negeert ook het verschil tussen hoofdletters en kleine letters bij Engelse letters, zodat “Lamp shade” wordt gevonden. Een patroon is nuttig om mogelijke overeenkomsten te vinden, maar bekijk die overeenkomsten voordat je ze wijzigt.

Kies een lijstvergelijking voor een lijst

UPDATE orders SET status = 'on hold'
WHERE customer_id IN (
  SELECT id FROM customers WHERE state = 'CA'
);

De subquery kan meerdere klantidentificaties leveren; IN controleert of een waarde in de lijst staat. Als je IN vervangt door =, vraag je om één scalaire waarde. PostgreSQL weigert daar meerdere rijen, terwijl SQLite ongemerkt de eerste teruggegeven rij gebruikt en andere klanten mist.

Vergelijk na de wijziging het aantal getroffen rijen met de selectie vooraf. PostgreSQL en SQLite kunnen ook RETURNING * toevoegen om de getroffen rijen te tonen. Start bij een risicovolle schrijfbewerking een transactie voordat je gegevens wijzigt, bekijk het resultaat en kies daarna COMMIT of ROLLBACK.

Een transactie bundelt samenhangende instructies tot één werkeenheid. Je beslist of je de wijzigingen samen vastlegt met COMMIT of samen terugdraait met ROLLBACK. De alles-of-niets-eigenschap heet atomiciteit, de A in ACID.

Behoud beide kanten van een overboeking

De rekening van Maya, ID 1, bevat € 500,00. De rekening van Leo, ID 2, bevat € 120,00. Voor het overboeken van € 75,00 zijn twee wijzigingen nodig:

BEGIN;
UPDATE accounts SET balance = balance - 75.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 75.00 WHERE id = 2;
SELECT id, balance FROM accounts WHERE id IN (1, 2);
COMMIT;

Na de eerste wijziging heeft Maya € 425,00. Na de tweede heeft Leo € 195,00. De controle toont beide saldi vóór het vastleggen en het totaal blijft € 620,00. Gebruik voor deze exacte decimale saldi PostgreSQL-NUMERIC; een SQLite-versie voor exacte geldbedragen slaat 50.000 en 12.000 cent op en boekt 7500 cent over.

Zonder expliciete transactie bij autocommit zou de eerste wijziging definitief kunnen worden voordat de tweede wordt uitgevoerd. Een crash daartussen zou de afschrijving behouden zonder de bijschrijving. Met een transactie neem je voor beide wijzigingen één definitieve beslissing om ze te behouden of terug te draaien. Handel een eventuele fout af voordat je besluit dat de overboeking is voltooid.

Begrijp de standaardgrens

Bij autocommit van de database wordt elke geslaagde afzonderlijke instructie als eigen transactie vastgelegd. Dit is de gebruikelijke begininstelling voor SQLite, PostgreSQL, MySQL en SQL Server. Een programmabibliotheek of client kan andere instellingen kiezen en een transactie voor je starten.

BEGIN; start een expliciete transactie in SQLite en PostgreSQL. SQLite en SQL Server gebruiken ook BEGIN TRANSACTION; PostgreSQL en MySQL accepteren START TRANSACTION. Oracle start een transactie bij een gegevenswijziging en wacht in programma's zoals SQL*Plus gewoonlijk op COMMIT, tenzij autocommit is ingeschakeld.

COMMIT beëindigt de transactie en legt de wijzigingen vast. ROLLBACK beëindigt de transactie en draait de niet-vastgelegde wijzigingen terug. Een latere terugdraaiing kan niet voorbij een eerdere vastlegging gaan.

Bekijk en draai terug

BEGIN;
DELETE FROM orders;
SELECT * FROM orders;
ROLLBACK;

Je verbinding ziet bij de SELECT een lege tabel en na de terugdraaiing weer de vijf orders. Het lege resultaat was werkelijk binnen de transactie, maar nog niet definitief. Andere verbindingen zien de niet-vastgelegde wijzigingen normaal gesproken niet.

Een transactie kan je alleen beschermen tegen een verkeerde rijselectie als je die bekijkt en besluit haar terug te draaien. SQL kan een onbedoelde rij met succes bijwerken: geen enkele databaseregel weet welke rekening je bedoelde. Vergelijk teruggegeven identificatiewaarden, waarden en aantallen met het bedoelde resultaat voordat je vastlegt.

Houd transacties kort en beëindig ze. Open transacties kunnen vergrendelingen vasthouden waardoor andere verbindingen moeten wachten; SQLite staat slechts één schrijver tegelijk toe. Als je een verbinding met een onvoltooide transactie sluit, worden de nog niet vastgelegde wijzigingen teruggedraaid. Wanneer een bibliotheek automatisch een transactie start, moet het programma de commitmethode aanroepen om het werk vast te leggen.

Een mislukte instructie heeft niet in elke database hetzelfde effect. Je moet weten wat nog niet is vastgelegd voordat je beslist hoe je herstelt. Een savepoint kan een tussenliggend punt bieden waarnaar je binnen een open transactie kunt terugkeren.

Volg een fout

Na de overboeking heeft Maya € 425,00 en Leo € 195,00. De tabel heeft CHECK (balance >= 0). Start een transactie en trek € 30,00 af van Maya: haar nog niet vastgelegde saldo is € 395,00. Probeer vervolgens € 300,00 van Leo af te trekken. Dat zou zijn saldo op -€ 105,00 brengen, dus de tweede instructie mislukt.

Als je in SQLite op dit punt vastlegt, blijft alleen Maya's afschrijving behouden. In PostgreSQL beëindigt COMMIT op de mislukte transactie deze met een terugdraaiing. Een duidelijke herstelprocedure is ROLLBACK uitvoeren, de oorzaak corrigeren en de samenhangende instructies opnieuw uitvoeren. Beide saldi keren dan vóór de gecorrigeerde poging terug naar € 425,00 en € 195,00.

Draai een later deel terug met een savepoint

BEGIN;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
SAVEPOINT after_first;
UPDATE accounts SET balance = balance + 10 WHERE id = 2;
ROLLBACK TO after_first;
COMMIT;

Het savepoint komt na Maya's verhoging. ROLLBACK TO draait Leo's latere verhoging terug, maar behoudt die van Maya. De eindsaldi zijn € 435,00 en € 195,00. Dit beëindigt de buitenste transactie niet; COMMIT doet dat.

RELEASE after_first verwijdert het savepoint zonder de wijzigingen erna terug te draaien. Het is geen zelfstandige definitieve vastlegging binnen de buitenste transactie. PostgreSQL staat ook toe dat ROLLBACK TO naar een savepoint van vóór een fout de mislukte toestand opheft en vanaf dat punt doorgaat.

Controleer of structuurwijzigingen kunnen worden teruggedraaid

SQLite en PostgreSQL staan CREATE TABLE, ALTER TABLE en DROP TABLE toe binnen transacties. Zo herstelt BEGIN; DROP TABLE orders; ROLLBACK; de tabel en de rijen.

Gewone DDL voor permanente tabellen veroorzaakt in MySQL en Oracle impliciete vastleggingen. Een CREATE TABLE, ALTER TABLE, DROP TABLE of TRUNCATE TABLE kan zowel eerdere, nog niet vastgelegde wijzigingen vastleggen als de eigen structuurbewerking uitvoeren. Een latere terugdraaiing kan dat eerdere werk niet ongedaan maken. Ga er niet van uit dat alle databasedialecten zich hetzelfde gedragen doordat een script binnen een transactie staat.

Begin bij een risicovolle gegevenswijziging de transactie, voer de schrijfbewerking uit, bekijk de waarden en het aantal en leg daarna vast of draai terug. Bekijk bijvoorbeeld de prijzen van verlichting na UPDATE products SET price = ROUND(price * 1.10, 2) WHERE category = 'lighting';. Neem de beslissing snel, zodat de transactie ander werk niet laat wachten.

ALTER TABLE wijzigt de structuur van een bestaande tabel en behoudt de rijen. UPDATE wijzigt de waarden in die rijen. Een kortingsveld toevoegen vereist ALTER TABLE; de al opgeslagen kortingen verhogen vereist UPDATE.

Voeg velden toe en hernoem ze

ALTER TABLE customers ADD COLUMN phone TEXT;
ALTER TABLE customers RENAME COLUMN phone TO mobile;
ALTER TABLE customers RENAME TO clients;

SQLite en PostgreSQL delen deze vormen. Een nieuwe kolom geeft bestaande rijen de standaardwaarde, of NULL als die er niet is. ADD COLUMN active INTEGER NOT NULL DEFAULT 1 geeft elke huidige rij een active-waarde van 1. email TEXT NOT NULL zonder standaardwaarde toevoegen aan een gevulde tabel mislukt omdat de bestaande rijen dan een verplichte waarde zouden missen.

SQLite ondersteunt RENAME COLUMN vanaf 3.25.0 en DROP COLUMN vanaf 3.35.0. Werk bij het hernoemen applicatiecode en opgeslagen query's bij die naar de oude naam verwijzen. SQL buiten de database kan de nieuwe naam niet automatisch ontdekken.

Vul gegevens voordat je ze verplicht maakt

Voeg in PostgreSQL een kolom toe die NULL toestaat, vul de bestaande rijen met geschikte waarden en maak de kolom pas daarna verplicht:

ALTER TABLE customers ADD COLUMN email TEXT;
UPDATE customers SET email = 'unknown@example.com'
WHERE email IS NULL;
ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

Dit laat zien hoe je een verplicht veld vult; het verklaart e-mail niet uniek. Een echte unieke e-mailkolom heeft verschillende geldige waarden nodig. SET NOT NULL mislukt als er ontbrekende waarden overblijven. PostgreSQL ondersteunt ook het wijzigen van een type met ALTER COLUMN price TYPE NUMERIC(10, 2), het instellen van een standaardwaarde en het toevoegen van een benoemde controle. Bestaande rijen moeten aan een nieuw toegevoegde regel voldoen.

Verwijder een veld of bouw een tabel opnieuw op

ALTER TABLE customers DROP COLUMN mobile; verwijdert het veld en alle opgeslagen waarden daarin. Afhankelijkheden kunnen de bewerking blokkeren. SQLite weigert een kolom te verwijderen die een primaire sleutel of refererende sleutel is, uniek of geïndexeerd is, of door een ander schemaobject wordt gebruikt. PostgreSQL kan afhankelijke objecten verwijderen met CASCADE, waaronder een view die de kolom gebruikt.

SQLite kan het type van een bestaande kolom niet wijzigen of primaire-sleutel-, uniekheids-, refererende-sleutel- of CHECK-regels aan bestaande kolommen toevoegen met een eenvoudige ALTER. Versie 3.53.0 voegt ALTER COLUMN ... SET NOT NULL en DROP NOT NULL toe, geen algemene bewerking van integriteitsregels. Een nieuw toegevoegde kolom kan een controle of toegestane verwijzing hebben, maar geen PRIMARY KEY of UNIQUE; als refererende sleutels zijn ingeschakeld, heeft een toegevoegde verwijzing een standaardwaarde NULL nodig.

Voor een uitgebreidere wijziging in SQLite:

1. Leg vast welke indexen, triggers en views opnieuw moeten worden gemaakt. Schakel refererende sleutels vóór de transactie uit als ze aanstaan.
2. Start een transactie en maak een nieuwe tabel met de gewenste regels.
3. Kopieer rijen met expliciete kolommen in INSERT INTO new_products (...) SELECT ... FROM products;.
4. Verwijder de oude tabel en hernoem de nieuwe naar products.
5. Maak afhankelijke objecten opnieuw en voer PRAGMA foreign_key_check; uit. Los eventuele gemelde problemen op voordat je vastlegt.
6. Leg vast en herstel daarna de handhaving van refererende sleutels als die eerder aanstond.

MySQL wijzigt definities met MODIFY COLUMN; SQL Server gebruikt ALTER COLUMN. Zet een structuurwijziging vóór uitvoering om naar de syntaxis die de doeldatabase ondersteunt.

DROP TABLE verwijdert zowel de tabel als de inhoud. Na DROP TABLE archived_orders; kunnen query's die tabel niet meer lezen omdat ze niet meer bestaat. De integriteitsregels, indexen en triggers worden mee verwijderd.

Kies het niveau van verwijdering

DROP TABLE IF EXISTS archived_orders; voorkomt een fout als de tabel ontbreekt. Een bestaande tabel en de bijbehorende gegevens worden nog steeds verwijderd. Een installatiescript dat tabellen verwijdert en opnieuw maakt, wist gegevens als je het uitvoert op een database met records die je wilt behouden.

Houd rekening met koppelingen tussen tabellen

Verwijder kinderen vóór ouders, in omgekeerde volgorde van de gebruikelijke aanmaakvolgorde. In PostgreSQL mislukt het verwijderen van customers zolang een refererende sleutel van een order ervan afhankelijk is. DROP TABLE customers CASCADE; verwijdert ook de afhankelijke refererende sleutel en eventuele afhankelijke views. De ordertabel en de rijen blijven bestaan, maar de klantrelatie wordt niet meer gehandhaafd.

Deze PostgreSQL-CASCADE verschilt van ON DELETE CASCADE bij een refererende sleutel. De eerste verwijdert afhankelijke databaseobjecten tijdens een structuurwijziging. De tweede verwijdert kindrijen wanneer een ouderrij wordt verwijderd. Als je weet welke actie wordt gebruikt, voorkom je een verkeerde voorspelling over de resterende gegevens.

Als de handhaving van refererende sleutels in SQLite is ingeschakeld, voert het verwijderen van een tabel eerst een impliciete verwijdering van de rijen uit. Verwijzende kinderen kunnen dit blokkeren. Als de relatie ON DELETE CASCADE declareert, kunnen die kindrijen worden verwijderd; SET NULL kan hun koppelingen leegmaken. Bij het verwijderen van een tabel moet je dus even goed op verwijzingen letten als bij het verwijderen van rijen, en daarnaast op de tabelstructuur die wordt verwijderd.

Zorg dat herstel mogelijk blijft

Bewaar een bruikbare kopie voordat je een tabel met echte gegevens verwijdert of opnieuw opbouwt. Een snelle interne gegevenskopie is:

CREATE TABLE products_backup AS
SELECT * FROM products;

In SQLite en PostgreSQL blijven hiermee de geselecteerde gegevens bewaard, maar niet de oorspronkelijke integriteitsregels. Dit vormt geen volledige reconstructie van de tabeldefinitie. Een export of databaseback-up bewaart herstelgegevens buiten de tabel die wordt gewijzigd.

In SQLite en PostgreSQL kun je het verwijderen ook binnen een transactie testen:

BEGIN;
DROP TABLE archived_orders;
ROLLBACK;

De terugdraaiing herstelt de tabel en de rijen omdat de verwijdering niet was vastgelegd. Zodra de verwijdering is vastgelegd, kun je die niet meer terugdraaien door later ROLLBACK uit te voeren. In databases met impliciete DDL-vastleggingen biedt transactiesyntaxis rond de verwijdering deze herstelmogelijkheid niet. Bekijk de doeldatabase en de betrokken tabellen voordat je een heropbouwscript uitvoert.