19 sep 2025·8 min
Donald Chamberlin en SQL: databases eenvoudig doorzoeken
Hoe Donald Chamberlin hielp SQL te ontwikkelen bij IBM, waarom de Engels-achtige syntaxis belangrijk was en hoe SQL de standaard werd om databases te raadplegen.
Hoe Donald Chamberlin hielp SQL te ontwikkelen bij IBM, waarom de Engels-achtige syntaxis belangrijk was en hoe SQL de standaard werd om databases te raadplegen.
Donald D. Chamberlin is geen bekende naam in elk huishouden, maar zijn werk heeft stilletjes bepaald hoe de meeste softwareteams met data omgaan. Als onderzoeker bij IBM hielp Chamberlin SQL (oorspronkelijk gespeld SEQUEL) te creëren, de taal die het praktisch maakte voor dagelijkse ontwikkelaars — en zelfs niet-specialisten — om vragen te stellen aan grote databases.
Voor SQL betekende antwoorden halen uit opgeslagen data vaak het schrijven van maatwerkprogramma's of het gebruiken van gereedschappen die krachtig maar onhandig waren. Chamberlin zette een ander idee voor: in plaats van de computer stap voor stap te vertellen hoe de data gevonden moest worden, moest je kunnen beschrijven wat je wilt in een vorm die dicht bij gewoon Engels leest.
Het hart van SQL is een verrassend mensvriendelijke aanpak:
SELECT)FROM)WHERE)Die structuur klinkt nu vanzelfsprekend, maar het was een grote verschuiving. Het veranderde “een database raadplegen” van een specialistische taak in iets dat je kon leren, delen, reviewen en verbeteren — net als elk ander onderdeel van softwareontwikkeling.
Dit is een praktische geschiedenis van hoe SQL ontstond en waarom het zich zo wijd verspreidde.
Je hebt geen gevorderde wiskunde, formele logica of diepe databasetheorie nodig om mee te komen. We richten ons op de reële problemen die SQL oploste, waarom het ontwerp benaderbaar was en hoe het een standaardvaardigheid werd in de softwarebranche — van backend-ontwikkeling tot analytics, productwerk en operatie.
Als je ooit een lijst hebt gefilterd, resultaten hebt gegroepeerd of twee gegevenssets hebt gekoppeld, dan dacht je al in de richting die SQL populair maakte. Chamberlins blijvende bijdrage was deze manier van denken omzetten in een taal die mensen echt konden gebruiken.
Vóór SQL “vroegen” de meeste organisaties geen database. Ze werkten met data opgeslagen in bestanden — vaak één bestand per applicatie — beheerd door het programma dat het maakte. Salarisadministratie had eigen bestanden, voorraad had eigen bestanden en klantgegevens konden verdeeld zijn over meerdere systemen.
Die bestand-gebaseerde aanpak werkte totdat bedrijven antwoorden wilden die grenzen overschreden: “Welke klanten kochten product X en hebben ook openstaande facturen?” Zo’n overzicht krijgen betekende data aan elkaar knopen die niet ontworpen waren om gecombineerd te worden.
In veel vroege systemen waren dataformaten sterk gekoppeld aan de applicatie. Een wijziging op één plek — zoals het toevoegen van een nieuw veld voor het telefoonnummer van een klant — kon vereisen dat programma’s herschreven werden, bestanden geconverteerd werden en documentatie aangepast werd. Zelfs toen “databasesystemen” begonnen te verschijnen, boden veel nog lage-niveau toegangsmethoden die meer aanvoelden als programmeren dan als het stellen van vragen.
Als je informatie wilde, had je meestal twee opties:
Geen van beide opties ondersteunde makkelijke verkenning. Een kleine wijziging in de vraag — een datumbereik toevoegen, groeperen per regio, retouren uitsluiten — kon een nieuw ontwikkeltraject worden. Het resultaat was een bottleneck: mensen met vragen moesten wachten op mensen die code konden schrijven.
Wat organisaties misten was een gedeelde manier om data-vragen uit te drukken — iets precies genoeg voor machines, maar leesbaar genoeg voor mensen. Businessgebruikers denken in termen van “klanten”, “bestellingen” en “totaal”. Systemen daarentegen waren gebouwd rond bestandsindelingen en procedurele stappen.
Deze kloof schiep de vraag naar een querytaal die intentie in actie kon vertalen: een consistente, herbruikbare manier om te zeggen wat je van data wilt zonder elke keer een nieuw programma te schrijven. Die behoefte bereidde het podium voor SQL’s doorbraak.
Voordat SQL kon bestaan, had de databasewereld een duidelijkere denkwijze over data nodig. Het relationele model bood dat: een eenvoudige, consistente structuur waarin informatie wordt opgeslagen in tabellen (relaties), bestaande uit rijen en kolommen.
De kernbelofte van het relationele model was simpel: stop met het bouwen van ad-hoc, moeilijk te onderhouden datastructuren voor iedere applicatie. Sla data op in een standaardvorm en laat verschillende programma’s verschillende vragen stellen zonder de opslagstructuur telkens te herschrijven.
Deze verschuiving was belangrijk omdat het twee vaak verstrengelde zaken scheidde:
Wanneer die zorgen gescheiden zijn, wordt data makkelijker te delen, veiliger bij updates en minder afhankelijk van de eigenaardigheden van een specifieke applicatie.
Edgar F. Codd, werkzaam bij IBM, hielp dit idee formaliseren en uitleggen waarom het beter was dan records door vaste paden navigeren. Je hoeft niet de volledige academische achtergrond te hebben om de impact te waarderen: hij gaf de industrie een model waarover je kon redeneren, testen en verbeteren.
Zodra data in tabellen leeft, is de natuurlijke volgende vraag: hoe vragen gewone mensen wat ze nodig hebben? Niet door naar opslaglocaties te wijzen, maar door het resultaat te beschrijven.
Die “beschrijf wat je wilt”-aanpak — selecteer deze kolommen, filter deze rijen, verbind deze tabellen — bereidde de weg voor een mensvriendelijke querytaal. SQL werd gebouwd om van dat model te profiteren en relationele theorie om te zetten in dagelijks werk.
IBM System R was aanvankelijk geen commercieel product — het was een onderzoeksproject dat een praktische vraag probeerde te beantwoorden: kon Edgar F. Codd’s relationele model in de echte wereld werken, op echte schaal, met echte bedrijfsdata?
Destijds werden veel databasesystemen genavigeerd via fysieke toegangspaden en record-voor-record logica. Relationele databases beloofden iets anders: sla data op in tabellen, beschrijf relaties helder en laat het systeem uitvogelen hoe de resultaten opgehaald moeten worden. Maar die belofte hing van twee dingen af: een relationele motor die goed presteerde en een querytaal die gewone ontwikkelaars (en sommige niet-ontwikkelaars) konden gebruiken.
System R, ontwikkeld in IBMs San Jose Research Laboratory in de jaren 70, had als doel een prototype relationeel databasebeheersysteem te bouwen en het relationele idee onder druk te zetten.
Net zo belangrijk onderzocht het technieken die nu fundamenteel zijn — vooral query-optimalisatie. Als gebruikers hoge-niveau verzoeken zouden schrijven (“haal deze records op die aan deze voorwaarden voldoen”), moest het systeem die verzoeken automatisch in efficiënte operaties vertalen.
Donald Chamberlin, werkzaam binnen IBMs onderzoeksomgeving, richtte zich op het ontbrekende stukje: een praktische taal om vragen te stellen aan relationele data. Samen met medewerkers (onder meer Raymond Boyce) werkte hij aan de vormgeving van een querytaal die aansloot bij hoe mensen van nature data-behoeften beschrijven.
Dit was geen taalontwerp in een vacuüm. System R leverde de feedbackloop: als een taalkenmerk niet efficiënt geïmplementeerd kon worden, overleefde het niet. Als een kenmerk gewone taken makkelijker maakte, kreeg het momentum.
Codd had het relationele model beschreven met formele wiskunde (relationele algebra en relationele calculus). Die ideeën waren krachtig, maar te academisch voor het dagelijks werk. System R had een taal nodig die:
Die zoektocht — geworteld in een werkend relationeel prototype — legde het fundament voor SEQUEL en later SQL.
Donald Chamberlin en zijn collega’s noemden hun nieuwe taal oorspronkelijk SEQUEL, kort voor Structured English Query Language. De naam verwees naar het kernidee: in plaats van procedurele code te schrijven om data stap voor stap te navigeren, zou je zeggen wat je wilt in een vorm die dicht bij alledaags Engels aanvoelde.
SEQUEL werd later afgekort tot SQL (praktisch gezien korter en makkelijker om te printen en uit te spreken, en ook vanwege naam- en merkenkwesties). Maar de ambitie van “structured English” bleef.
Het ontwerpsdoel was om werken met databases te laten voelen als het doen van een duidelijke aanvraag:
Die structuur gaf mensen een consistent mentaal model. Je hoefde niet de speciale navigatieregels van een leverancier te leren; je leerde een leesbaar patroon om vragen te stellen.
Stel een eenvoudige zakelijke vraag: “Welke klanten in Californië hebben dit jaar het meest uitgegeven?” SQL laat je die intentie direct uitdrukken:
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE state = 'CA' AND order_date >= '2025-01-01'
GROUP BY customer_id
ORDER BY total_spent DESC;
Zelfs als je nieuw bent met databases, kun je vaak raden wat dit doet:
Die leesbaarheid — gekoppeld aan precieze regels — hielp SQL ver buiten IBM System R te reizen en de bredere softwarewereld in te gaan.
Een reden dat SQL bleef hangen is dat het je een vraag laat uitdrukken zoals je die hardop zou zeggen: “Pak deze dingen, van deze plaats, met deze voorwaarden.” Je hoeft niet hoe je het antwoord moet vinden stap voor stap te beschrijven; je beschrijft wat je wilt.
SELECT = pak de kolommen die je wilt zien.
FROM = vanuit welke tabel (of dataset) die feiten moeten komen.
WHERE = filter de rijen zodat alleen de relevante overblijven.
JOIN = koppel gerelateerde tabellen aan elkaar (zoals customer_id in orders aan diezelfde customer_id in customers).
GROUP BY = vat samen per categorie, zodat je kunt praten over totalen “per klant”, “per maand” of “per product”.
SELECT customer_name, COUNT(*) AS order_count
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.status = 'Shipped'
GROUP BY customer_name;
Lees het als: “Pak de naam van elke klant en het aantal bestellingen, uit orders gekoppeld aan customers, houd alleen verzonden bestellingen aan en vat samen per klant.”
Als SQL ooit intimiderend voelt, stap dan terug en formuleer je doel in één regel. Zet die woorden vervolgens om:
Die vraag-eerst gewoonte is het echte “mensvriendelijke” ontwerp achter SQL.
SQL introduceerde niet alleen een nieuwe manier om met data te praten — het verlaagde wie een “databasepersoon” moest zijn om antwoorden te krijgen. Voorheen betekende een vraag aan een database vaak procedurele code schrijven, opslagdetails begrijpen of een verzoek indienen bij een specialistisch team. Chamberlins werk keerde dat om: je kon beschrijven wat je wilde, en de database zorgde voor hoe het opgehaald werd.
SQLs grootste toegankelijkheidswinst is dat het leesbaar genoeg is om te delen tussen analisten, ontwikkelaars en productteams. Zelfs een beginner kan de intentie van een query zoals deze begrijpen:
SELECT product, SUM(revenue)
FROM sales
WHERE sale_date >= '2025-01-01'
GROUP BY product;
Je hoeft de indexstructuren of bestandsindelingen niet te kennen om te zien wat er gevraagd wordt: totale omzet per product over een datumbereik.
Omdat SQL declaratief en wijdverspreid is, werd het een gemeenschappelijk referentiepunt tijdens planning en debugging. Een productmanager kan de vraag sanity-checken (“Tellen we retouren mee?”). Een analist kan definities aanpassen. Een engineer kan performance optimaliseren of logica verplaatsen naar een applicatie of pipeline.
Net zo belangrijk maakt SQL de “vraag” zelf reviewbaar. Het kan versiebeheer hebben, van commentaar worden voorzien, getest en verbeterd — net als code.
SQL maakt het vragen makkelijker, maar het garandeert geen betrouwbare antwoorden. Je hebt nog steeds nodig:
SQL opende de deur naar self-service datawerk, maar goede resultaten hangen nog steeds af van goede data en gedeelde betekenis.
SQL won niet omdat het de enige querytaal was — het won omdat het praktisch was voor een groeiende industrie die gedeelde gewoonten nodig had. Toen teams zagen dat SQL hen in staat stelde duidelijke vragen over data te stellen zonder voor elk rapport maatwerkcode te schrijven, begon het in meer producten, opleidingen en vacature-eisen op te duiken.
Naarmate databaseleveranciers SQL ondersteunden, volgde andere software. Rapportagetools, business-intelligence dashboards en later applicatieframeworks profiteerden allemaal van één gemeenschappelijke manier om data op te halen en te vormen.
Dat creëerde een positieve lus:
Zelfs wanneer databases intern verschilden, maakte een vertrouwd SQL-“oppervlak” het makkelijker om van systeem te wisselen of systemen te integreren.
Portabiliteit betekent niet “draait overal zonder aanpassingen”. Het betekent dat de kernideeën — SELECT, WHERE, JOIN, GROUP BY — herkenbaar blijven tussen producten. Een query geschreven voor één systeem heeft vaak maar kleine aanpassingen nodig voor een ander. Dat verlaagde vendor lock-in en maakte migraties minder eng.
In de loop van de tijd werd SQL gestandaardiseerd: een gedeelde set regels en definities die leveranciers grotendeels ondersteunen. Zie het als grammatica voor een taal. Verschillende regio’s hebben accenten en dialecten, maar basisgrammatica maakt communicatie mogelijk.
Voor mensen en organisaties had die standaardisatie grote effecten:
Het eindresultaat: SQL werd de standaard “gemeenschappelijke taal” voor werken met relationele data.
SQL veranderde niet alleen hoe mensen data opvragen — het veranderde hoe software wordt gebouwd. Zodra er een gemeenschappelijke manier was om vragen aan een database te stellen, konden hele categorieën producten ervan uitgaan dat “SQL beschikbaar is” en focussen op hogere-level features.
Je ziet SQL in bedrijfsapplicaties (CRM, ERP, financiële systemen), in rapportagedashboards en achter webservices die records ophalen en bijwerken. Zelfs wanneer gebruikers nooit een query typen, genereren veel apps nog steeds SQL onder de motorkap om orders te filteren, totalen te berekenen of een klantprofiel samen te stellen.
Die alomtegenwoordigheid creëerde een krachtig patroon: als je software SQL spreekt, kan het met veel verschillende databasesystemen werken met minder custom integratie.
Een gedeelde querytaal maakte het praktisch om tools te bouwen die rondom databases zitten:
Het belangrijkste punt is dat deze tools niet aan één leverancier gebonden zijn — ze vertrouwen op SQL-concepten die overdraagbaar zijn.
Een reden dat SQL nog steeds relevant is in 2025, is dat het fungeert als een duurzaam contract tussen intentie en uitvoering. Zelfs wanneer je apps bouwt met hogere-level tools — of met AI — heb je nog steeds een databaselaag nodig die expliciet, testbaar en controleerbaar is.
Bijvoorbeeld op Koder.ai (een vibe-coding platform om web-, backend- en mobiele apps via chat te maken) onderbouwen teams vaak “wat de app moet doen” met heldere relationele tabellen en SQL-queries. Onder de motorkap betekent dat doorgaans een Go-backend met PostgreSQL, waarbij SQL de gedeelde taal blijft voor joins, filters en aggregaten — terwijl het platform scaffolding, iteratie en deployment versnelt.
SQL heeft decennia meegedraaid en daarmee ook decennia verzamelde kritiek. Veel klachten zijn in een smalle context valide, maar ze worden vaak herhaald zonder de praktische nuance waarop werkende teams vertrouwen.
SQL lijkt simpel als je SELECT ... FROM ... WHERE ... ziet, en dan ineens enorm: joins, groeperingen, window-functies, common table expressions, transacties, permissies, performance-tuning. Die sprong kan frustrerend zijn.
Een nuttig kader is dat SQL klein in het midden en groot aan de randen is. De kernideeën — rijen filteren, kolommen kiezen, tabellen combineren, aggregaten — zijn snel te leren. Complexiteit verschijnt vooral wanneer je precies wilt zijn over reële data (missende waarden, duplicaten, tijdzones, rommelige identifiers) of wanneer je op snelheid op schaal mikt.
Sommige “rare” gedragingen zijn eigenlijk SQL die eerlijk is over data. Bijvoorbeeld, NULL staat voor “onbekend”, niet voor “nul” en niet voor een lege string, dus vergelijkingen gedragen zich anders dan veel mensen verwachten. Een andere verrassing is dat dezelfde query rijen in een andere volgorde kan teruggeven tenzij je expliciet sorteert — omdat een tabel geen spreadsheet is.
Dit zijn geen redenen om SQL te vermijden; het zijn herinneringen dat databases kiezen voor correctheid en duidelijkheid boven impliciete aannames.
Deze kritiek verwart twee dingen:
Leveranciers voegen functies toe om te concurreren en hun gebruikers te bedienen — extra functies, andere datumafhandeling, proprietaire extensies, gespecialiseerde indexering, procedurele talen. Daarom heeft een query die in het ene systeem werkt soms kleine aanpassingen nodig in een ander systeem.
Begin met het beheersen van draagbare basics: SELECT, WHERE, JOIN, GROUP BY, HAVING, ORDER BY en basis INSERT/UPDATE/DELETE. Als dat natuurlijk voelt, kies dan de database die je het meest gebruikt en leer de specifieke sterke punten (en eigenaardigheden).
Als je zelf leert, helpt het ook om een persoonlijk spiekbriefje van verschillen bij te houden. Dat maakt van “dialecten vervelend” het realistischer “ik weet waar ik op moet letten”.
SQL leren draait minder om syntaxis uit het hoofd leren en meer om een gewoonte opbouwen: stel een duidelijke vraag en vertaal die in een query.
Begin met één kleine tabel (denk: customers of orders) en oefen data lezen voordat je iets “doet”.
WHERE en ORDER BY. Word comfortabel met alleen de kolommen selecteren die je nodig hebt.orders + customers) met JOIN.GROUP BY om vragen als “hoeveel?” en “hoeveelheid?” te beantwoorden — counts, sums, averages en maandelijkse totalen.Deze volgorde weerspiegelt hoe SQL is ontworpen: breek een vraag in delen en laat de database uitzoeken wat de beste uitvoering is.
Als je oefent op een gedeelde database — of nieuw bent en bang iets verkeerd te klikken — bescherm jezelf met een paar regels:
SELECT. Zie het als “read mode.”LIMIT 50 toe (of het equivalent in je database) zodat je niet per ongeluk miljoenen rijen ophaalt.DELETE, UPDATE, DROP) totdat je WHERE-clausules volledig begrijpt en een veilige sandbox hebt.SELECT-versie van de WHERE-conditie uit om te verifiëren welke rijen veranderd zouden worden.Goede SQL-oefening lijkt op echt werk:
Kies één vraag, schrijf de query en controleer of het resultaat logisch is. Die feedbackloop maakt SQL intuïtief.
Als je SQL leert terwijl je ook iets bouwt, helpt het om in een omgeving te werken waar schema, queries en applicatiecode dichtbij elkaar blijven. Bijvoorbeeld, wanneer je een kleine PostgreSQL-gestuurde app prototypeert in Koder.ai, kun je tabellen en queries snel itereren, snapshots maken en broncode exporteren wanneer je klaar bent — zonder het zicht op de daadwerkelijke SQL-logica te verliezen.
Donald Chamberlins blijvende bijdrage was niet alleen het uitvinden van syntaxis — het was het bouwen van een leesbare brug tussen mensen en data. SQL liet iemand beschrijven wat hij wilde (klanten in Californië, omzet per maand, producten met lage voorraad) zonder uit te leggen hoe een computer het stap voor stap moest ophalen. Die verschuiving maakte databasevragen van een specialistisch ambacht tot een gedeelde taal die teams konden bespreken, reviewen en verbeteren.
SQL blijft bestaan omdat het middenweg biedt: expressief genoeg voor complexe vragen, gestructureerd genoeg om geoptimaliseerd en gestandaardiseerd te worden. Zelfs als nieuwe datatools verschijnen — dashboards, no-code interfaces en AI-assistenten — blijft SQL de betrouwbare laag eronder. Veel moderne systemen vertalen klikken, filters en prompts naar SQL-achtige operaties, omdat databases dat kunnen valideren, beveiligen en efficiënt uitvoeren.
Interfaces veranderen, maar organisaties hebben nog steeds behoefte aan:
SQL voldoet aan die eisen. Het is niet perfect, maar het is leerbaar — en die leerbaarheid is deel van de uitvinding.
Chamberlins echte nalatenschap is het idee dat de beste tools krachtige systemen benaderbaar maken. Als een taal leesbaar is, nodigt ze meer mensen uit in het gesprek — en zo verspreidt technologie zich van laboratoria naar het dagelijks werk.
Donald D. Chamberlin was een IBM-onderzoeker die SQL (oorspronkelijk SEQUEL genoemd) mede ontwikkelde als onderdeel van het System R-project. Zijn belangrijkste bijdrage was het mede vormgeven van een declaratieve, leesbare taal zodat mensen databases om resultaten konden vragen zonder stap-voor-stap programma’s te hoeven schrijven.
SQL maakte data-toegang deelbaar en herhaalbaar. In plaats van telkens een nieuw custom programma aan te vragen of afhankelijk te zijn van vaste rapporten, konden teams queries schrijven en reviewen zoals elke andere taak, wat verkenning versnelde en knelpunten verminderde.
Een declaratieve taal vertelt de database wélk resultaat je wilt, niet de procedure om het te halen. In de praktijk beschrijf je kolommen, tabellen, filters en groeperingen, en kiest de database (via query-optimisatie) een efficiënte manier om het uit te voeren.
Het basis-mentale model is:
SELECT: wat je wilt zien (kolommen of expressies)FROM: waar het vandaan komt (tabellen/views)WHERE: welke rijen in aanmerking komen (filters)Als dat duidelijk is, kun je toevoegen om tabellen te verbinden, om samen te vatten en om te sorteren.
Een JOIN combineert rijen uit twee (of meer) tabellen op basis van een matchende voorwaarde—meestal een gedeelde identifier zoals customer_id. Gebruik joins wanneer de benodigde informatie verdeeld is over meerdere tabellen (bijvoorbeeld bestellingen in één tabel en klantnamen in een andere).
GROUP BY laat je resultaten “per categorie” produceren (totaal per klant, aantallen per maand, omzet per product). Een praktische werkwijze is:
SELECT ... FROM ... WHERE ... die de juiste rijen teruggeeft.COUNT(), , .System R was IBMs prototype uit de jaren 70, gebouwd om te bewijzen dat relationele databases in de praktijk op echte schaal konden werken. Het introduceerde ook belangrijke ideeën zoals query-optimalisatie, waardoor een hoog-niveau taal zoals SQL praktisch werd omdat het systeem verzoeken in efficiënte stappen kon omzetten.
SQL verspreidde zich omdat het een gemeenschappelijke interface werd voor veel databases en tools. Dat creëerde een versterkende lus:
Zelfs met verschillen tussen producten bleven de kernconcepten herkenbaar.
SQL-dialecten bestaan echt, maar de meest effectieve aanpak is:
SELECT, WHERE, , , en basis .Begin veilig en bouw in lagen:
JOINGROUP BYORDER BYSUM()AVG()JOINGROUP BYORDER BYINSERT/UPDATE/DELETEDat verandert incompatibiliteiten in beheersbare naslagpunten in plaats van constante frustratie.
SELECTLIMIT toe (of het equivalente in je DB) om niet per ongeluk miljoenen rijen te trekken.UPDATE/DELETE eerst dezelfde WHERE als SELECT uit om te zien welke rijen beïnvloed zouden worden.Het doel is om duidelijke vragen in queries te vertalen, niet syntax uit het hoofd te leren zonder context.