Plaatjes in de database
Uit Yapf
Is het nu wel of niet verstandig of handig om plaatjes in een database op te slaan? Het antwoord is niet zo zwart wit, er kleven voor- en nadelen aan het opslaan van plaatjes in een database.
Inhoud |
Het probleem
Het probleem gaat in het bijzonder over plaatjes, foto's en dergelijken. Waarom: die worden op websites vaak met meerdere tegelijk op een pagina getoond en dus ook met meerdere tegelijk door de browser opgevraagd. In HTML worden plaatjes echter getoond door een IMG tag te maken die verwijst naar een URL waar de binaire data van het plaatje gevonden kan worden. Deze data wordt door de browser dan ook per plaatje met een aparte HTTP request opgehaald.
Tien plaatjes geeft dus ook tien HTTP requests. Data uit een database kan alleen worden gebruikt door het eerst met een query op te halen dus moeten er tien PHP scripts worden gestart die elk een query draaien om de data op te halen.
Op een drukke website worden dat al snel honderden/duizenden queries per minuut en omdat het meestal om meerdere tientallen/honderden kilobytes aan informatie gaat staat je database al snel alleen maar binaire data naar de webserver te pompen en het enige wat die doet is de data doorgeven.
Het compromis
De database is zeer goed in het bijhouden van gegevens, en de webserver is bijzonder goed in het dom doorgeven van rauwe data. Het licht dus voor de hand om beiden te gebruiken voordatgene waar ze goed in zijn: Laat de database bijhouden welke plaatjes bestaan en zet de binaire data van die plaatjes als bestanden op disk zodat de webserver er bij kan.
Persoonlijk vind ik het handig om de binaire data van plaatjes ook in de database te zetten en dan die inhoud te kopieren naar een cache bestand wat de webserver vervolgens gebruikt om door te geven aan de bezoeker.
In de IMG tag van de HTML staat dus de URL van het cachebestand op disk, niet een link naar een PHP script.
Voordelen
- Je gebruikt de webserver zoals hij bedoeld is: om bestanden door te geven.
- De webserver zal ook de browsercache gebruiken.
- De plaatjes staan centraal in een database wat handig kan zijn bij backups.
Nadelen
- Wanneer een bestaand plaatje moet worden bewerkt dan moet het eerst met een query uit de database worden gelezen en later weer met een query worden teruggeplaatst
- De backup van de database wordt heel veel groter, wat in sommige gevallen een probleem kan zijn.
Voor de gevorderden: databases zoals PostgreSQL hebben ook zogenaamnde untrusted stored procedures, die ook toegang hebben tot het fileysteem. Daarmee kun je via triggers dus ook het maken en wissen van de cachebestanden koppelen aan het inserten/deleten van het blobrecord.
De veelgebruikte manier
De meest gebruikte manier verschilt niet veel met bovenstaande, alleen het plaatje wordt niet in de database gezet, maar alleen de naam, omschrijving etc. Verder wordt de PK nog wel gebruikt als bestandsnaam (alleen dat is veilig). Op deze manier blijft de database klein en spaar je je de moeite om code te schrijven om plaatjes in de database te zetten en eruit te lezen.