Drie redenen waarom je voor Postgres zou moeten kiezen in plaats van MySQL

Het maken van views is mogelijk met MySQL en Postgres, maar er is een groot verschil. Postgres biedt de mogelijkheid om een materialized view aan te maken. Voordat we uitleggen wat het grote voordeel is, moeten we misschien even een stapje terugdoen. Want wat is een view? Een view is eigenlijk gewoon het resultaat van een bepaalde query, die je op kunt slaan en daarna kunt benaderen alsof het een gewone tabel is.

Stel dat je een gebruikerstabel hebt waarin de voor- en achternaam opgeslagen zijn in aparte velden, maar het handiger is om dit samen te voegen tot één veld. Dan zou je ervoor kunnen kiezen om dit in je query op te lossen (CONCAT). Je kunt er ook eenmalig een view van maken. Op die manier hoef je niet steeds de voor- en achternaam samen te voegen, maar kun je het ophalen alsof het een veld is.

Tot zover niks bijzonders, want beide databases kunnen dit voor elkaar krijgen. Onder water is een view gewoon een query die op dat moment wordt uitgevoerd. Je kunt je voorstellen dat het niet altijd even snel is. Zeker niet wanneer je bepaalde berekeningen uitvoert in je query. Dit is precies waar een materialized view om de hoek komt kijken. Wanneer je zo’n soort view aanmaakt, wordt je view opgeslagen alsof het een echte tabel is. Dit zorgt ervoor dat je de data veel sneller kunt benaderen. De query hoeft namelijk niet steeds opnieuw uitgevoerd te worden. Een groot voordeel als je veel data hebt en je applicatie afhankelijk is van een snelle presentatie van die data. Een materialized view wordt overigens niet steeds opnieuw opgebouwd, dit zul je wel zelf moeten regelen. Het heeft dus vooral een groot voordeel bij het lezen van de data.

Indexes zijn een belangrijke manier om databases te optimaliseren. Wanneer je een tabel met gebruikers hebt en je bijvoorbeeld alleen gebruikers uit Nederland wilt, doe je er goed aan om een index te creëren voor het veld waar het land is opgeslagen. MySQL en Postgres bieden beide de mogelijkheid om verschillende soorten indexen te leggen op bepaalde velden, maar dit doe je dan wel altijd op de gehele dataset.

Postgres biedt naast de normale indexen ook nog de mogelijkheid om partial indexes aan te maken. Het komt er op neer dat je een index aanmaakt met een WHERE-clausule erin. Het kan voorkomen dat je gebruikers uit meerdere landen hebt, maar in de code alleen maar gebruikers uit Nederland wilt selecteren. Dan is een normale index eigenlijk iets te veel van het goede en kun je beter gaan voor een partial index. Omdat het vaak om een kleinere set data gaat, zal het resultaat ook sneller opgehaald kunnen worden.

Zowel MySQL als Postgres hebben de mogelijkheid om constraints (beperkingen) toe te voegen aan een tabel. De meest voor de hand liggende is de zogenaamde primary key. Deze gebruik je om een bepaalde rij te kunnen identificeren. Wanneer je bijvoorbeeld een tabel hebt met gebruikers, heeft elke gebruiker ook een id waarmee je de gegevens van die gebruiker snel kunt ophalen (SELECT * FROM users WHERE id = 1). Dit veld is altijd uniek. Zo weet je zeker dat je de juiste informatie krijgt als je daarom vraagt.

De primary key wordt ook gebruikt voor het leggen van relaties tussen verschillende tabellen. Daarnaast is er ook nog de mogelijkheid om een veld uniek te maken binnen een bepaalde tabel. Denk bijvoorbeeld aan een e-mailadres in een gebruikerstabel. Hiervoor maak je gebruik van een zogenaamde unique key. Hierbij verschillen MySQL en Postgres nog niet van elkaar, maar Postgres kent nog een derde constraint: check. Deze geeft je de mogelijkheid om je eigen beperking op te leggen voor de waarde van een bepaald veld. Zo kun je ervoor zorgen dat de waarde binnen een bepaalde range valt. Bijvoorbeeld een getal hoger dan 100, maar kleiner dan 1000. Dit zijn zaken die je normaal vaak op probeert te lossen door middel van validaties, maar Postgres biedt deze mogelijkheden gewoon standaard aan. Het grote voordeel is dat je zeker weet dat je data voldoet aan bepaalde regels en dat je niet afhankelijk bent van de code die de data in je database stopt.

Een ander voorbeeld waarin deze constraint erg handig kan zijn, is wanneer je werkt met datums. Misschien wil je zeker weten dat de startdatum eerder is dan de einddatum, dan kun je dat eenvoudig controleren met een simpele check. Zo zijn er nog talloze voorbeelden te verzinnen waarin deze constraint goed van pas zou komen. Hoewel MySQL hier geen ondersteuning voor heeft, heeft het alternatief MariaDB dit wel sinds versie 10.2.1.