[alg] Plaatjes in de database?

[Janoz]

Dit topic is afgesplitst van Davio in "[alg] Slechtste programmeervoorbeelden d..."

Davio schreef op vrijdag 16 juli 2010 @ 16:54:
Wij maken gebruik van een database waar plaatjes in opgeslagen worden (als CLOBs of BLOBs).

FragFrog schreef op vrijdag 16 juli 2010 @ 17:28:
[...]

TRWTF

_{Niet al te serieus nemen, ik wil best geloven dat het in jullie situatie wel de beste oplossing is}

TRWTF is dat er nog steeds mensen zijn die denken dat het opslaan van plaatjes een WTF is .

[ Voor 32% gewijzigd door Janoz op 19-07-2010 13:10 ]

[FragFrog]

Janoz schreef op maandag 19 juli 2010 @ 09:27:
TRWTF is dat er nog steeds mensen zijn die denken dat het opslaan van plaatjes een WTF is .

Je bedoelt opslaan van plaatjes in een DB? Als het niet nodig is: ja. Het is flink trager dan files direct door je webserver laten afhandelen en het zorgt ervoor dat je DB backups onnodig groot worden _{met MySQL in elk geval}. Ik ken weinig scenario's waarin het echt een significant voordeel heeft.

[ Voor 3% gewijzigd door FragFrog op 19-07-2010 09:58 ]

[Woy]

FragFrog schreef op maandag 19 juli 2010 @ 09:54:
[...]
Het is flink trager dan files direct door je webserver laten afhandelen

Dat is nog maar de vraag, ook je database heeft gewoon een cache, en anders kun je natuurlijk nog steeds gebruik maken van andere caching mechanismen.

en het zorgt ervoor dat je DB backups onnodig groot worden _{met MySQL in elk geval}.

Je database backup word inderdaad groter, maar anders moet je nog steeds ook je file-system backupen, dus je zal er netto niet zo veel verschil mee merken.

Ik ken weinig scenario's waarin het echt een significant voordeel heeft.

Het grote voordeel is dat je alle informatie gewoon bij elkaar hebt staan, en dat de kans dus een stuk kleiner is dat dingen out sync raken. Stel dat je bijvoorbeeld een backup van je database terug moet zetten, dan ben je in een keer klaar. Anders moet je ook nog maar zien te zorgen dat je backup van je file-system gelijk loopt met je backup van je database. Het hoeft dus helemaal niet zo slecht te zijn, en bied wel degelijk voordelen. Maar zoals met alles, zul je per situatie moeten kijken wat de beste oplossing is.

[FragFrog]

Woy schreef op maandag 19 juli 2010 @ 10:20:
Dat is nog maar de vraag, ook je database heeft gewoon een cache, en anders kun je natuurlijk nog steeds gebruik maken van andere caching mechanismen.

Toevallig heb ik dat van de week nog lopen benchmarken (nav een andere opmerking hier), op mijn testserver is het grofweg een kwart sneller om filesystem te gebruiken dan een MySQL database (link). Wellicht dat er situaties zijn waar dit niet geldt, maar ik ben ze nog niet tegengekomen

Je database backup word inderdaad groter, maar anders moet je nog steeds ook je file-system backupen, dus je zal er netto niet zo veel verschil mee merken.

Met het verschil dat je (wederom: met MySQL) niet (makkelijk) incremental DB dumps kan maken. Als je een hash van een plaatje gebruikt om alleen unieke afbeeldingen op te slaan kun je erg eenvoudig images backuppen door enkel nieuwe files naar je backup locatie te kopieeren - als een plaatje toch verandert krijgt die ook een nieuwe hash en refereer je domweg daarheen. Afgezien van al je blobs in een aparte DB opslaan ken ik geen methode om ze niet elke backup opnieuw op te slaan.

Stel dat je bijvoorbeeld een backup van je database terug moet zetten, dan ben je in een keer klaar. Anders moet je ook nog maar zien te zorgen dat je backup van je file-system gelijk loopt met je backup van je database.

Als je een complete backup terug moet zetten, dus inclusief je file-system, zul je ook je source-code terug moeten zetten (voor PHP in elk geval). Sla je images op in een folder samen met je code kun je die ook simpelweg in een enkele handeling terugzetten. Sterker nog, als je ze los opslaat en een aparte fileserver gebruikt voor statische files (wat vaak nog de netste oplossing is) heb je grote kans dat je juist niets hoeft terug te zetten als je DB / webserver crashed - dan is het juist geen extra werk, en je DB restore zal des te sneller zijn omdat er minder data geinsert hoeft te worden

Natuurlijk, er zijn wel situaties waarin het wel handig is (vooral als je bij elk image request toch al security-details uit je DB moet halen) en sommige DBRMS's kunnen er beter mee overweg dan anderen (ik begrijp dat SQL Server 2008 bijvoorbeeld blobs vrij efficient afhandelt) maar ik gok dat in de meeste gevallen je beter het FS kan gebruiken.

[ Voor 7% gewijzigd door FragFrog op 19-07-2010 10:44 ]

[Janoz]

FragFrog schreef op maandag 19 juli 2010 @ 10:34:
Toevallig heb ik dat van de week nog lopen benchmarken (nav een andere opmerking hier), op mijn testserver is het grofweg een kwart sneller om filesystem te gebruiken dan een MySQL database (link). Wellicht dat er situaties zijn waar dit niet geldt, maar ik ben ze nog niet tegengekomen

MySQL is maar 1 van de vele. Het lijkt me niet handig om op basis van een bench op 1 enkele database een complete architectuur keuze te maken. Daarnaast is snelheid maar 1 van de vele requirements die je kunt hebben. Verder is het natuurlijk niet zo dat je de plaatjes ook alleen maar uit de database mag lezen. Niks houdt je tegen om een cache op het FS te maken waar je de plaatjes weghaalt. Het snelheids argument is dan volledig onderuit gehaald.

Met het verschil dat je (wederom: met MySQL) niet (makkelijk) incremental DB dumps kan maken. Als je een hash van een plaatje gebruikt om alleen unieke afbeeldingen op te slaan kun je erg eenvoudig images backuppen door enkel nieuwe files naar je backup locatie te kopieeren - als een plaatje toch verandert krijgt die ook een nieuwe hash en refereer je domweg daarheen. Afgezien van al je blobs in een aparte DB opslaan ken ik geen methode om ze niet elke backup opnieuw op te slaan.

Zie boven mbt architectuurkeuzes baseren op 1 enkele database implementatie. Daarnaast, de incrementele backup procedure waarbij je naast een database ook nog een deel van je filesystem moet gaan backuppen (en deze backups ook goed in sync moet houden) is een stuk lastiger dan enkel een database backup. En Murphy dicteert in dat geval 2 dingen:
1 - Als iets lastiger is gaat dat veel vaker fout
2 - Als iets fout kan gaan, gaat het ook fout op het moment dat het het minst goed uitkomt.

Als je een complete backup terug moet zetten, dus inclusief je file-system, zul je ook je source-code terug moeten zetten (voor PHP in elk geval).

Als je je data terug wilt/moet zetten betekend dat helemaal niet automatisch dat je ook je code terug moet zetten. Die oorzaak gevolg koppeling bestaat helemaal niet. Er is een groot verschil tussen je content (data) aan de ene kant en je code/software aan de andere kant.

Sla je images op in een folder samen met je code kun je die ook simpelweg in een enkele handeling terugzetten. Sterker nog, als je ze los opslaat en een aparte fileserver gebruikt voor statische files (wat vaak nog de netste oplossing is) heb je grote kans dat je juist niets hoeft terug te zetten als je DB / webserver crashed - dan is het juist geen extra werk, en je DB restore zal des te sneller zijn omdat er minder data geinsert hoeft te worden

En dan praat je over onnodig grote backups? Wanneer je je code telkens weer mee opslaat bij je plaatjes ben je sowieso niet goed bezig. Wanneer de poep de ventilator geraakt heeft neem ik aan dat je je applicatie gewoon weer uit je repository kunt trekken en je content uit de backups. Plaatjes in de DB zorgt ervoor dat de content uit 1 bron komt die gegarandeerd in sync is met elkaar (want 1 bron kan natuurlijk erg lastig niet in sync zijn met zichzelf). Wanneer je je content uit 2 compleet verschillende bronnen moet halen is het heel lastig om die in sync te houden (tenzij jij een transactional systeem hebt waarin je je filesystem en je DB op kunt nemen)

Natuurlijk, er zijn wel situaties waarin het wel handig is (vooral als je bij elk image request toch al security-details uit je DB moet halen) en sommige DBRMS's kunnen er beter mee overweg dan anderen (ik begrijp dat SQL Server 2008 bijvoorbeeld blobs vrij efficient afhandelt) maar ik gok dat in de meeste gevallen je beter het FS kan gebruiken.

Voor de redelijk simpele Yet Another Webapp is het vaak toereikend, maar in alle gevallen ga ik bij het opzetten van een architectuur altijd uit van een 'In de database, tenzij..'-approach.

[FragFrog]

Janoz schreef op maandag 19 juli 2010 @ 11:25:
MySQL is maar 1 van de vele. Het lijkt me niet handig om op basis van een bench op 1 enkele database een complete architectuur keuze te maken.

Mijn uitspraken zijn dan ook onder voorbehoud van implementatie-keuzes. Nochtans gok ik dat het resultaat bij andere databases weinig zal verschillen: hoe je het ook went of keert, uiteindelijk moet de data eerst van de DB naar je script en van je script naar de user, in plaats van directe pass-thru wat je bij een webserver of bijvoorbeeld PHP's readFile methode hebt.

Daarnaast is snelheid maar 1 van de vele requirements die je kunt hebben. Verder is het natuurlijk niet zo dat je de plaatjes ook alleen maar uit de database mag lezen. Niks houdt je tegen om een cache op het FS te maken waar je de plaatjes weghaalt. Het snelheids argument is dan volledig onderuit gehaald.

En vervolgens krijg je problemen met concurrency en cache invalidation. Ik dacht dat jij juist voorstander was van dingen simpel houden? Ik gok dat een goede cache controle en filesystem cache net iets complexer is om op te zetten dan een simpele filebackup.

Daarnaast, de incrementele backup procedure waarbij je naast een database ook nog een deel van je filesystem moet gaan backuppen (en deze backups ook goed in sync moet houden) is een stuk lastiger dan enkel een database backup. En Murphy dicteert in dat geval 2 dingen:
1 - Als iets lastiger is gaat dat veel vaker fout
2 - Als iets fout kan gaan, gaat het ook fout op het moment dat het het minst goed uitkomt.

Hangt af van je platform. Onder windows server kan ik een folder selecteren, onder properties de backup wizzard doorlopen en in een paar klikken een automatische incremental backup schedulen. Dat is zelfs nog minder werk dan een speciale task maken die een mysqldump doet, het resultaat correct renamed en verplaatst naar een backup locatie. Incremental file-backups zijn wel zo gemeengoed dat dit nauwelijks een issue mag zijn qua complexiteit.

En dan praat je over onnodig grote backups? Wanneer je je code telkens weer mee opslaat bij je plaatjes ben je sowieso niet goed bezig.

Met incremental backups is dat juist geen issue. Evengoed heb je gelijk dat de source ook uit een repository kan trekken, ik had het over een situatie waarin dat niet zo geregeld is (wat helaas in mijn ervaring nog te vaak voorkomt), of waarbij local changes zijn gemaakt (idem).

Plaatjes in de DB zorgt ervoor dat de content uit 1 bron komt die gegarandeerd in sync is met elkaar (want 1 bron kan natuurlijk erg lastig niet in sync zijn met zichzelf). Wanneer je je content uit 2 compleet verschillende bronnen moet halen is het heel lastig om die in sync te houden (tenzij jij een transactional systeem hebt waarin je je filesystem en je DB op kunt nemen)

Wellicht nogmaals ter verduidelijking: wanneer je van elk image wat je hebt, een unieke fingerprint van het origineel maakt, het origineel met die fingerprint als naam opslaat, en bij elke wijziging een nieuw plaatje maakt met zijn eigen unieke fingerprint heb je ook nagenoeg nooit problemen met synchronisatie, zolang je FS backups maar even vaak gemaakt worden als DB backups (wat simpeler is dan het lijkt: er is genoeg backup software die continue wijzigingen automatisch toevoegt aan een incremental backup, bij MySQL moet je dan al bezig met dumps en binlogs).

Ik zal niet ontkennen dat het (iets) simpeler is om backups op te zetten als je alles op 1 locatie houdt: dat is evident. Maar om voor die paar uitzonderingsituaties standaard alles in je DB te plempen lijkt me, zeker als het om veel binaire data gaat, een slecht plan. Wederom, wellicht dat andere databases er beter mee omgaan, maar ik heb enig ervaring met grote MySQL databases (1Gb+ aan data) en de problemen met backups, replication, caching, etc wegen voor mij niet op tegen het extra werk van een filebackup task toevoegen. Daar komt bij dat ik geregeld een DB backup terug moet zetten maar nagenoeg nooit een compleet filesystem. Al heeft dat wellicht ook te maken met die troep die MySQL heet

YopY schreef op maandag 19 juli 2010 @ 11:51:
Een kwart valt mee, als je die plaatjes ook nog eens encrypted opgeslagen hebt.

Dat is unencrypted En dan ben ik vrij gul: in de meest ideale situatie is MySQL 27% langzamer. Ga ik ook leuren met connecties openen etc wordt het al 38% langzamer. Ter vergelijking: memcache doet er "slechts" 15% langer over.

offtopic:
Wellicht een idee trouwens om deze discussie af te splitsen naar een apart draadje? Het begint wat offtopic te raken.

[ Voor 5% gewijzigd door FragFrog op 19-07-2010 12:18 ]

[Janoz]

FragFrog schreef op maandag 19 juli 2010 @ 12:10:
[...]

Mijn uitspraken zijn dan ook onder voorbehoud van implementatie-keuzes. Nochtans gok ik dat het resultaat bij andere databases weinig zal verschillen: hoe je het ook went of keert, uiteindelijk moet de data eerst van de DB naar je script en van je script naar de user, in plaats van directe pass-thru wat je bij een webserver of bijvoorbeeld PHP's readFile methode hebt.

Nogmaals. Snelheid is vaak niet de enige requirement waar je mee te maken hebt en uit een cache lezen is natuurlijk net zo snel (of misschien sneller omdat je van bepaalde uitgangspunten uit kunt gaan waardoor je beter kunt optimaliseren).

En vervolgens krijg je problemen met concurrency en cache invalidation. Ik dacht dat jij juist voorstander was van dingen simpel houden? Ik gok dat een goede cache controle en filesystem cache net iets complexer is om op te zetten dan een simpele filebackup.

Oneens. Plaatjes wijzigen weinig en je weet ook exact wanneer ze gewijzigd worden. Invalideren is dan ook erg triviaal. Daarnaast kun je zonder bang te zijn dat je de state van de applicatie corrupeert de hele cache leeggooien. Dat heeft enkel een tijdelijke performance impact. Daarnaast blijkt uit de onderstaande tekst wel dat je de complexiteit van een fatsoenlijke backup schromelijk onderschat.

Hangt af van je platform. Onder windows server kan ik een folder selecteren, onder properties de backup wizzard doorlopen en in een paar klikken een automatische incremental backup schedulen. Dat is zelfs nog minder werk dan een speciale task maken die een mysqldump doet, het resultaat correct renamed en verplaatst naar een backup locatie. Incremental file-backups zijn wel zo gemeengoed dat dit nauwelijks een issue mag zijn qua complexiteit.

De complexiteit zit hem dan ook niet in de incrementele backup van het filesystem en de incrementele backup van de DB, maar in de combinatie. Op geen enkele manier heb jij afgedwongen dat de state van de database hoort bij de state van het filesystem. 'Het is van ongeveer hetzelfde moment dus dat zal wel loslopen'

Met incremental backups is dat juist geen issue. Evengoed heb je gelijk dat de source ook uit een repository kan trekken, ik had het over een situatie waarin dat niet zo geregeld is (wat helaas in mijn ervaring nog te vaak voorkomt), of waarbij local changes zijn gemaakt (idem).

Kan ik niet over spreken. Ik ben over het algemeen toch wel redelijk fatsoenlijk ingerichte enterprise omgevingen gewend (alhoewel ik daar ook wel regelmatig enorme WTF's tegenkom)

Wellicht nogmaals ter verduidelijking: wanneer je van elk image wat je hebt, een unieke fingerprint van het origineel maakt, het origineel met die fingerprint als naam opslaat, en bij elke wijziging een nieuw plaatje maakt met zijn eigen unieke fingerprint heb je ook nagenoeg nooit problemen met synchronisatie, zolang je FS backups maar even vaak gemaakt worden als DB backups (wat simpeler is dan het lijkt: er is genoeg backup software die continue wijzigingen automatisch toevoegt aan een incremental backup, bij MySQL moet je dan al bezig met dumps en binlogs).
[...]
Ik zal niet ontkennen dat het (iets) simpeler is om backups op te zetten als je alles op 1 locatie houdt: dat is evident. Maar om voor die paar uitzonderingsituaties standaard alles in je DB te plempen lijkt me, zeker als het om veel binaire data gaat, een slecht plan. Wederom, wellicht dat andere databases er beter mee omgaan, maar ik heb enig ervaring met grote MySQL databases (1Gb+ aan data) en de problemen met backups, replication, caching, etc wegen voor mij niet op tegen het extra werk van een filebackup task toevoegen. Daar komt bij dat ik geregeld een DB backup terug moet zetten maar nagenoeg nooit een compleet filesystem. Al heeft dat wellicht ook te maken met die troep die MySQL heet

Als enkel het filebackup taakje aanmaken genoeg was geweest zou je een punt kunnen hebben.

Het punt is dat het enige echte argument dat jij hebt mbt het opslaan op het FS de snelheid is. Ik geef aan dat doormiddel van caching van de data op het FS dit probleem niet meer bestaat. Voor de rest draag je imho houwtje touwtje oplossingen aan om de integriteit te kunnen bewaren.

Ik ben niet fundamenteel tegen het opslaan van content op het FS. Ik ageer alleen sterk tegen mensen die het opslaan van data in de database een WTF vinden. Vaak is dit gebaseerd op compleet verkeerde uitgangspunten.

[JaQ]

Janoz schreef op maandag 19 juli 2010 @ 13:05:
Het punt is dat het enige echte argument dat jij hebt mbt het opslaan op het FS de snelheid is. Ik geef aan dat doormiddel van caching van de data op het FS dit probleem niet meer bestaat. Voor de rest draag je imho houwtje touwtje oplossingen aan om de integriteit te kunnen bewaren.

Bij een Oracle database is het opslaan en ophalen van (binaire) data (bijvoorbeeld plaatjes, maar ook bijvoorbeeld XML) uit een database met een serieuze setup niet trager dan van een filesystem. Ik heb zelfs testen uitgevoerd waar ik een hogere snelheid haalde dan vanaf een willekeurig NAS (dat kan ook iets zeggen over de configuratie van het NAS ).

Wat ik wel vaak zie is dat uiteindelijk de front-end software (java) dermate dom omgaat met LOBs dat het geheel alsnog traag wordt. Dat is echter geen databaseprobleem .

[FragFrog]

Janoz schreef op maandag 19 juli 2010 @ 13:05:
De complexiteit zit hem dan ook niet in de incrementele backup van het filesystem en de incrementele backup van de DB, maar in de combinatie. Op geen enkele manier heb jij afgedwongen dat de state van de database hoort bij de state van het filesystem. 'Het is van ongeveer hetzelfde moment dus dat zal wel loslopen'

Het enige probleem waar je op de manier die ik voorstel tegenaan zou kunnen lopen is dat je DB backup nieuwer is dan je filebackup: in dat geval heb je links in je DB die niet overeenkomen met daadwerkelijk aanwezige data - en ja, ik noem het triviaal om een script te schrijven wat dat controleert - meer dan een dozijn regels code zul je niet nodig hebben. Zodra je zorgt dat images direct gebacked up worden zodra ze zijn ingevoerd (triviaal met de juiste tools) speelt het hele probleem al niet meer. Immers, het is helemaal niet erg als een afbeelding wel in je FS staat maar niet in de DB..

Worst case scenario is dus als je DB vaker gebacked up wordt dan je FS, en in dat geval moet je een scriptje runnen om ongeldige images uit je DB te halen. Dat is het grootst mogelijke synchronisatie-probleem waar je tegenaan kan lopen, wat erg simpel voorkomen kan worden - veel simpeler dan een (snelle) filesystem cache bouwen. In mijn opinie weegt dat niet op tegen de nadelen

Als enkel het filebackup taakje aanmaken genoeg was geweest zou je een punt kunnen hebben.

Het punt is dat het enige echte argument dat jij hebt mbt het opslaan op het FS de snelheid is. Ik geef aan dat doormiddel van caching van de data op het FS dit probleem niet meer bestaat.

Hier ben ik het niet mee eens: zoals gezegd spelen ook andere zaken een rol: de grootte van je DB backup, de tijd die het duurt om de backup te draaien (een MySQL dump is best snel, maar met een gig aan data ben alsnog een paar minuten plat), de hoeveelheid geheugen in je DB server (als binaire data in je resultcache komt zul je die navenant moeten vergroten), complexiteit (ga maar eens een folderstructuur emuleren) en inderdaad niet geheel onbelangrijk: snelheid. Dat noem ik niet '1" argument, in tegenstelling tot de reden om wel alles in je DB te gooien "dan heb je geen synchronisatie problemen" - een punt wat je makkelijk kan voorkomen en in de praktijk zelfs nagenoeg nooit tegenkomt.

Ik ben niet fundamenteel tegen het opslaan van content op het FS. Ik ageer alleen sterk tegen mensen die het opslaan van data in de database een WTF vinden. Vaak is dit gebaseerd op compleet verkeerde uitgangspunten.

Andersom vind ik data opslaan in een DB niet perse een WTF (zie de opmerking in mijn originele reactie ), maar wel als er geen goede reden voor is meer dan "het is wel makkelijk". Als je met zo'n instelling gaat coden kom je al snel de limieten van je hardware tegen

offtopic:
Wellicht speelt het trouwens dat ik voornamelijk met PHP werk, de taal is leuk maar niet al te vlot. Dan ga je wat meer concentreren op snelheid

[JaQ]

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
Het enige probleem waar je op de manier die ik voorstel tegenaan zou kunnen lopen is dat je DB backup nieuwer is dan je filebackup:

Bij een "mickey mouse"-systeem misschien, maar stel nu eens dat je belangrijke data hebt (contracten binnen een bank bijvoorbeeld, of foto's van een flitspaal om een andere dwarsstraat te noemen) en aan zaken als point in time recovery wilt doen? En dan begin ik nog niet over incremental backups.

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
Hier ben ik het niet mee eens: zoals gezegd spelen ook andere zaken een rol: de grootte van je DB backup, de tijd die het duurt om de backup te draaien (een MySQL dump is best snel, maar met een gig aan data ben alsnog een paar minuten plat),

Er bestaan databases die je online kan backupen

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
de hoeveelheid geheugen in je DB server (als binaire data in je resultcache komt zul je die navenant moeten vergroten),

Absoluut, je kan niet met 5kb RAM extra toe. Echter als je goede performance op FS wilt halen zal je ook e.e.a. moeten doen aan de performance van dit FS.

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
complexiteit (ga maar eens een folderstructuur emuleren)

Als eens van hierarchical queries gehoord?

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
en inderdaad niet geheel onbelangrijk: snelheid.

Snelheid is flauwekul, althans: bij Oracle is dit geen argument.

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
Dat noem ik niet '1" argument, in tegenstelling tot de reden om wel alles in je DB te gooien "dan heb je geen synchronisatie problemen" - een punt wat je makkelijk kan voorkomen en in de praktijk zelfs nagenoeg nooit tegenkomt.

Die praktijk van jou is erg afhankelijk van het type systeem

FragFrog schreef op maandag 19 juli 2010 @ 14:22:
Andersom vind ik data opslaan in een DB niet perse een WTF (zie de opmerking in mijn originele reactie ), maar wel als er geen goede reden voor is meer dan "het is wel makkelijk".

Helemaal eens. Je moet altijd je code (en je database) aanpassen op de eisen van de klant / de omgeving. Daarom kan je uitgangspunten die je kent vanuit MySQL niet extrapoleren naar andere databases

Er is geen altijd juist antwoord op de vraag of je binaire data in een database of op het filesystem moet opslaan. De vraag kent teveel variabelen om een constant antwoord te produceren.

[B-Man]

Ik vind het grootste gemak dat je metadata + content van files centraal hebt in de database. Daarnaast kun je middels FKs eenvoudig afdwingen dat een file inclusief metadata compleet is, of niet bestaat.

Voor kleine omgevingen is het snel op te zetten, voor grote(re) omgevingen zitten er garanties aan vast.

Ik wijk enkel uit naar FS-based oplossingen als het om dermate veel bestanden/data gaat dat de grootte van de database een "probleem" wordt vwb het platform waar het op draait.

[Verwijderd]

Oracle is al genoemd. Microsoft SQL server bied mogelijkheden om beiden te doen (vanuit de Database): reviews: SQL Server 2008: een vooruitblik . Kon de review nog herinneren. Laten we het er maar op houden dat MySQL beperkt is.

Overigens: ik stop liever spullen in de DB.

[ Voor 6% gewijzigd door Verwijderd op 19-07-2010 19:36 ]

[Snake]

Niemand die Filestream noemt uit MSSQL? : http://geekswithblogs.net...2008-for-file-stream.aspx

[ACM]

JaQ schreef op maandag 19 juli 2010 @ 14:37:
Bij een "mickey mouse"-systeem misschien, maar stel nu eens dat je belangrijke data hebt (contracten binnen een bank bijvoorbeeld, of foto's van een flitspaal om een andere dwarsstraat te noemen) en aan zaken als point in time recovery wilt doen? En dan begin ik nog niet over incremental backups.

Je hebt ook filesystems die dat gewoon kunnen, zoals Oracle/Sun's ZFS... Daarmee kan je een punt in tijd bevriezen (snapshot) en daar eventueel ook apart een backup van maken (of een verzameling snapshots een tijdje bewaren). Er zijn uiteraard meer filesystems die dat kunnen, maar met ZFS heb ik zelf dan toevallig ervaring.

Er bestaan databases die je online kan backupen

Dat kan MySQL inderdaad ook. Voor consistente backups is MySQL nog wel wat onpraktisch zodra er MyISAM-tabellen bij komen kijken, magoed, dat is geen probleem van databases in het algemeen.

Absoluut, je kan niet met 5kb RAM extra toe. Echter als je goede performance op FS wilt halen zal je ook e.e.a. moeten doen aan de performance van dit FS.

Voordeel is wel dat je ook andere shortcuts kan nemen als je direct vanaf een filesystem werkt. Zoals een veel efficientere webserver gebruiken (lighttpd vs apache bijv) en dat je niet je database zowel voor je blobs als voor je gewone data moet zien te schalen en performant te houden. Maar dat alles is uiteraard voor zover relevant. Soms is data-veiligheid gewoon belangrijker.

Snelheid is flauwekul, althans: bij Oracle is dit geen argument.

Ik kan me niet voorstellen dat het net zo makkelijk is om het hele proces uit Oracle goede performance te halen (uren of dagen tunen van code, parameters en queries?), als uit een fatsoenlijk filesystem (wat het waarschijnlijk uit zichzelf direct goed doet met off-the-shelf beschikbare performante webservers)... Dus om het argument zo makkelijk opzij te vegen is dan ook niet heel netjes.
Daarbij kan je ook nog andere voordelen hebben zoals een beter gebruik van je SAN-bandbreedte (webservers die direct de images lezen, terwijl het niet allemaal via die ene verbinding van je database hoeft) etc etc. Het totale performance-plaatje is domweg veel complexer dan enkel database vs filesystem, maar zelfs daar vermoed ik dat je op zijn best in de buurt van een goed filesystem kan komen.

Overigens ben ik met je eens dat een goed caching-systeem sowieso in beide gevallen vereist is, want ook images die op disk wijzigen zou je op een of andere manier moeten kunnen communiceren naar gebruikers. In het geval van websites kan je dan het beste domweg een delete+create doen ipv een update, zodat je zeker weet dat gebruikers de nieuwe versie laden. Of uiteraard met caching-headers/timeouts werken. En zodra je een van die twee strategieen goed uitgewerkt hebt is het ook vrij triviaal om er een caching reverse proxy voor te zetten, waardoor je inderdaad een groot deel van het verschil in client-performance hebt verwijderd.

Er is geen altijd juist antwoord op de vraag of je binaire data in een database of op het filesystem moet opslaan. De vraag kent teveel variabelen om een constant antwoord te produceren.

Dat is de enige juiste conclusie Bij bijna alle architectuur- en programmeerproblemen overigens

[Davio]

Zou zoiets kunnen werken: http://www.faqs.org/rfcs/rfc2397.html ?

[Kettrick]

Davio schreef op dinsdag 20 juli 2010 @ 09:19:
Zou zoiets kunnen werken: http://www.faqs.org/rfcs/rfc2397.html ?

Het werkt vast

Groot nadeel is echter wel dat je voor elke request je blob in je request moet duwen, waardoor cachen praktisch onmogelijk wordt . Voor zover ik weet wordt dit vooral gebruikt om email attachements te versturen e.d.

[Davio]

Kettrick schreef op dinsdag 20 juli 2010 @ 09:31:
[...]


Het werkt vast

Groot nadeel is echter wel dat je voor elke request je blob in je request moet duwen, waardoor cachen praktisch onmogelijk wordt . Voor zover ik weet wordt dit vooral gebruikt om email attachements te versturen e.d.

Ja, maar het idee is dan dat ik alle plaatjes met één db request op kan halen en kan parsen in plaats van 600 requests.

[jbdeiman]

Zoals in de meeste gevallen waarin dit soort vragen worden gesteld is "inventariseren" het sleutelwoord..
Eerst goed bedenken wat het idee is met de bestanden, en vervolgens kijken of het nodig is om deze als blob in de database op te slaan.

Wat wij vaak doen (overigens niet met afbeeldingen) in onze applicatie is een exensieloos bestand opslaan met als naam het "id" van de file in de database. Daarbij wordt een file-/ mime-type (kan van alles zijn) opgeslagen. Bij het openen van het bestand uit het systeem worden de juiste headers meegegeven en voila.
Grote voordeel van zo'n systeem is dat je de bestanden eenvoudig kan backuppen. Bij ons was het niet handig geweest (ook wegens de grootte en de complexiteit van sommige bestanden)

Het is verder prima te doen om afbeeldingen als blob op te slaan, bij MySQL (zoals hiervoor al geschetst) verdient dat echter meestal niet de voorkeur, in andere situaties, met andere database systemen, kan dit wel weer een goede optie zijn.

Ik zou zo zeggen:
- Ga na wat de bedoeling is van de afbeeldingen en hoevaak deze vernieuwd/ veranderd worden.
- Ga na (testen) wat sneller is, met de files op je filesystem, of uit de Blob.
- Ga bij deze testen na wat je met cachen kan bereiken, bij opslaan als Blob.

1 goed antwoord bestaat niet, het is afhankelijk van meerdere factoren.

[FragFrog]

JaQ schreef op maandag 19 juli 2010 @ 14:37:
Bij een "mickey mouse"-systeem misschien, maar stel nu eens dat je belangrijke data hebt (contracten binnen een bank bijvoorbeeld, of foto's van een flitspaal om een andere dwarsstraat te noemen) en aan zaken als point in time recovery wilt doen? En dan begin ik nog niet over incremental backups.

Geen enkel probleem met fingerprints. Sterker nog, GiT werkt op nagenoeg hetzelfde principe, toch niet het minste of geringste version control system Of, zoals al gemeld, een FS gebruiken wat het ondersteunt. Natuurlijk, op een gegeven moment wordt de complexiteit zo groot dat het begint op te wegen tegen de nadelen, een bank-contract zal bijvoorbeeld ook niet zoveel eisen stellen aan performance als de header op een drukbezochte website.

Die praktijk van jou is erg afhankelijk van het type systeem

Absoluut waar. Toch is het vrij snel zo dat je wel een database crash kan hebben terwijl je FS intact is, maar een intacte DB terwijl het onderliggende FS stuk is zie je niet zo snel. Ik heb zelf een stuk vaker te maken met DB crashes dan FS crashes, wellicht een overgeneralisatie maar ik gok dat dit voor meer mensen geldt

Er is geen altijd juist antwoord op de vraag of je binaire data in een database of op het filesystem moet opslaan. De vraag kent teveel variabelen om een constant antwoord te produceren.

Helaas moet ik je hierin gelijkgeven, het is alleen zo'n dooddoener in elke discussie

[JaQ]

ACM schreef op maandag 19 juli 2010 @ 22:52:
Ik kan me niet voorstellen dat het net zo makkelijk is om het hele proces uit Oracle goede performance te halen (uren of dagen tunen van code, parameters en queries?), als uit een fatsoenlijk filesystem (wat het waarschijnlijk uit zichzelf direct goed doet met off-the-shelf beschikbare performante webservers)... Dus om het argument zo makkelijk opzij te vegen is dan ook niet heel netjes.

Het is inderdaad niet netjes om het performance argument gemakkelijk opzij te vegen, Echter een hoge snelheid (performance vind ik iets anders ) is ook met een filesystem nogal eens lastig te krijgen in een wat grotere omgeving (bijvoorbeeld met tienduizenden kleine bestandjes in 1 directory... etc etc) Ik haalde niet voor niets een wat groter voorbeeld aan, enkel om aan te tonen dat een "altijd juist" oplossing niet bestaat.

ACM schreef op maandag 19 juli 2010 @ 22:52:
Daarbij kan je ook nog andere voordelen hebben zoals een beter gebruik van je SAN-bandbreedte (webservers die direct de images lezen, terwijl het niet allemaal via die ene verbinding van je database hoeft) etc etc. Het totale performance-plaatje is domweg veel complexer dan enkel database vs filesystem, maar zelfs daar vermoed ik dat je op zijn best in de buurt van een goed filesystem kan komen.

Ik moet altijd een beetje lachen om SAN beheerders die mij stoer komen vertellen dat hun SAN zo snel is omdat ze wel 8 paden naar een machine aanbieden en 2 GB cache in dat SAN hebben zitten. Dat ondertussen een halve TB aan RAM in een RAC cluster bovenop dat SAN beschikbaar is doet er verder helemaal niet toe . Maar misschien werk ik met belachelijke omgevingen

overigens: er is een verband tussen de optimale grootte van een I/O van een OS, de I/O size van een SAN en het gedrag van een database. Daar weet jij vast ook wel e.e.a. over

Desalniettemin heb je gelijk dat bij een wat kleinere, eenvoudigere setup met weinig eisen een filesystem in veel gevallen de eenvoudigste manier is om een de hoogste snelheid te bieden.

ACM schreef op maandag 19 juli 2010 @ 22:52:
Dat is de enige juiste conclusie Bij bijna alle architectuur- en programmeerproblemen overigens

Uiteraard. Mijn favoriete antwoord is niet voor niets: 'it depends'.

FragFrog schreef op dinsdag 20 juli 2010 @ 09:48:
Geen enkel probleem met fingerprints. Sterker nog, GiT werkt op nagenoeg hetzelfde principe, toch niet het minste of geringste version control system

Dat een (groot?) pakket een bepaalde werkwijze gebruikt betekent niet dat het een goede werkwijze is Ik ken ladingen pakketen met alle logica in de GUI en een slow-by-slow processing die enorm veel gebruikt worden, maar in mijn optiek toch echt K zijn opgebouwd.

FragFrog schreef op dinsdag 20 juli 2010 @ 09:48:
Natuurlijk, op een gegeven moment wordt de complexiteit zo groot dat het begint op te wegen tegen de nadelen, een bank-contract zal bijvoorbeeld ook niet zoveel eisen stellen aan performance als de header op een drukbezochte website.

Maar dit is dus de hele grap. Het is echt een dooddoener, maar mooier dan "it depends" valt het niet te maken .

FragFrog schreef op dinsdag 20 juli 2010 @ 09:48:
Absoluut waar. Toch is het vrij snel zo dat je wel een database crash kan hebben terwijl je FS intact is, maar een intacte DB terwijl het onderliggende FS stuk is zie je niet zo snel. Ik heb zelf een stuk vaker te maken met DB crashes dan FS crashes, wellicht een overgeneralisatie maar ik gok dat dit voor meer mensen geldt

mmm.. in mijn situatie (ik ben DBA) heb ik toch meer last van filesystems die moeilijk doen. Misschien ligt dat aan het type database waar je mee werkt, of de grootte van de omgeving.

[ Voor 24% gewijzigd door JaQ op 20-07-2010 10:28 ]

[Wolfboy]

JaQ schreef op dinsdag 20 juli 2010 @ 10:08:
mmm.. in mijn situatie (ik ben DBA) heb ik toch meer last van filesystems die moeilijk doen. Misschien ligt dat aan het type database waar je mee werkt, of de grootte van de omgeving.

Idem.

Corrupte databases heb ik geen last meer van gehad sinds ik gestopt ben met het gebruiken van MySQL. Als een fatsoenlijke database (Oracle, MS SQL, Postgres) echt corrupt raakt dan ligt het meestal aan het onderliggende filesystem hier door een _zeer_ onprettige crash (denk kortsluiting/stroompiek zonder bbu en *poef* server uit).

Vaak genoeg corrupted filesystems gehad, maar corrupte databases... nagenoeg nooit bij een fatsoenlijk opgezette omgeving.

[ACM]

Wolfboy schreef op dinsdag 20 juli 2010 @ 13:14:
Vaak genoeg corrupted filesystems gehad, maar corrupte databases... nagenoeg nooit bij een fatsoenlijk opgezette omgeving.

Op vergelijkbare systemen, waar met vergelijkbare zorg de boel opgezet was? Want in mijn ervaring is een corrupt filesystem ook vrij zeldzaam en vooral te wijten aan dezelfde problemen die je voor databases aanhaalt

De meeste databases draaien bovenop een filesystem en zijn daarmee automatisch afhankelijk van de correcte werking van dat FS. Als je dus wel in staat bent daar bovenop een betrouwbare database op te zetten, maar niet om dat FS zonder database betrouwbaar in te zetten... dan klopt er toch iets niet.

[Wolfboy]

Zoals ik al zei, filesystem crashes door spontane stroomuitval e.d. ja. Ooit eens problemen gehad met een bijhoorlijk foutieve UPS maar geen vervanging in de buurt en geen zekerheid wat de oorzaak van de uitval was.

3x plotselinge stroomuitval. Eerste keer ging alles goed (damaged fs, maar werkte verder nog prima). 2e keer damaged filesystem. 3e keer damaged filesystem en lichtelijk corrupte database, maar met een repair direct gefixt.

Maargoed, gelijk heb je. In normale situaties zijn filesystem corrupties inderdaad zeer zeldzaam. Al verschilt dat uiteraard heel veel per filesystem. Met ReiserFS heb ik regelmatig corrupties gehad terwijl ZFS en UFS me nog nooit problemen hebben gegeven.

[FragFrog]

JaQ schreef op dinsdag 20 juli 2010 @ 10:08:
Dat een (groot?) pakket een bepaalde werkwijze gebruikt betekent niet dat het een goede werkwijze is

Absoluut waar, daar ken ik helaas maar al teveel voorbeelden van Evengoed is GiT geschreven door een of andere Linus, 't schijnt best aardig te werken, hij heeft ook een OS gemaakt en als ik me niet vergis gebruiken ze het ook voor version control van de source daarvan.

JaQ schreef op dinsdag 20 juli 2010 @ 10:08:
mmm.. in mijn situatie (ik ben DBA) heb ik toch meer last van filesystems die moeilijk doen. Misschien ligt dat aan het type database waar je mee werkt, of de grootte van de omgeving.

Of je bent gewoon een erg goede DBA en je collega's prutsen een beetje? Om een voorbeeld uit de praktijk aan te halen: even geleden had ik wat redelijk DB-intensieve software draaien op een dedicated gameserver, begon op een gegeven moment om de paar dagen vrij hard te crashen - telkens met een corrupte DB tot gevolg, terwijl het FS verder nog prima was. Volgens de hosting provider kwam het uiteindelijk door brak geheugen in die bak. Al was dat (uiteraard) MySQL en (uiteraard) met een config voor snelheid, niet data integriteit.

Sowieso zijn er meer redenen waarom een DB corrupt kan raken - hackers, slecht geschreven updates, etc. Ik heb helaas al eens meegemaakt dat een hacker met een gevoel voor humor alle namen in een table omgedraait had (een jaar of vijf geleden voor het laatst gelukkig, tegenwoordig iets meer kaas gegeten van beveiliging), toegang krijgen tot het FS is toch net wat lastiger en heb ik nog niet gezien _{in mijn eigen software dan}. Al met al zit ik toch veel vaker een DB te restoren dan een FS, maar wellicht was dat toch een overgeneralisatie en is de situatie in andere omgevingen juist andersom

[JaQ]

ACM schreef op dinsdag 20 juli 2010 @ 21:11:
Op vergelijkbare systemen, waar met vergelijkbare zorg de boel opgezet was? Want in mijn ervaring is een corrupt filesystem ook vrij zeldzaam en vooral te wijten aan dezelfde problemen die je voor databases aanhaalt

Eens. Misschien komt het doordat sommige Oracle DBA's met wat meer zorg hun omgeving opzetten (overigens werk ik nog zelden met een FS onder Oracle. Het is tegenwoordig enkel ASM wat de klok slaat).

FragFrog schreef op woensdag 21 juli 2010 @ 07:50:
Evengoed is GiT geschreven door een of andere Linus, 't schijnt best aardig te werken, hij heeft ook een OS gemaakt en als ik me niet vergis gebruiken ze het ook voor version control van de source daarvan.

Dat is geen argument. Microsoft heeft ook een aantal heel aardige stukken software geschreven. Dat is geen reden om dan maar aan te nemen dat alle software van Microsoft goed is (hetzelfde geldt voor Oracle overigens). Zodra je je helden blind gelooft en niet meer ter discussie durft te stellen, ga je m.i. een verkeerde weg in.

(let op: hiermee zeg ik dus niet dat GiT een slecht pakket is, ik weet veel te weinig over GiT om dat te zeggen. Het gaat me om je argumentatie om aan te tonen dat GiT "goed" is).

FragFrog schreef op woensdag 21 juli 2010 @ 07:50:
Of je bent gewoon een erg goede DBA en je collega's prutsen een beetje?

DBA's zijn altijd gevoelig voor veren in hun kont, daar ben ik geen uitzondering op. Ik ben zeker niet de beste DBA die je kan vinden, binnen Oracle kan ik me echter best aardig redden

overigens ben ik ZZP-er, dus je kan me altijd inhuren

FragFrog schreef op woensdag 21 juli 2010 @ 07:50:
Sowieso zijn er meer redenen waarom een DB corrupt kan raken - hackers, slecht geschreven updates, etc. Ik heb helaas al eens meegemaakt dat een hacker met een gevoel voor humor alle namen in een table omgedraait had (een jaar of vijf geleden voor het laatst gelukkig, tegenwoordig iets meer kaas gegeten van beveiliging), toegang krijgen tot het FS is toch net wat lastiger en heb ik nog niet gezien _{in mijn eigen software dan}. Al met al zit ik toch veel vaker een DB te restoren dan een FS, maar wellicht was dat toch een overgeneralisatie en is de situatie in andere omgevingen juist andersom

Wacht ff. Logische corruptie door slechte beveiliging of een slechte update is een heel ander probleem dat "een corrupte database". Een corrupte database is in mijn optiek een database waar door een fout in de databasesoftwarede opgeslagen data niet langer meer te lezen (of muteren) is. Ook een storing in een component buiten de database (bijvoorbeeld SAN, filesystem of OS) kan een dergelijke corruptie veroorzaken. Door een stroomstoring zou je bijvoorbeeld nooit een niet-integere database mogen overhouden. De lopende transacties worden netjes teruggerold en je database blijft in een integere staat. (mits je software tenminste transacties die bij elkaar horen ook als 1 transactie uitvoerd).

Een slechte update die logische corruptie veroorzaakt is een typische voorbeeld van een matig ontwikkelproces. Een inbraak is een typisch voorbeeld van een matige beveiliging. Tegen beide situaties kan databasesoftware je niet tegen beschermen (maakt niet uit welk smaakje je gebruikt).

Uiteindelijk hebben we het over zero-data-loss (toch?) Daarnaast heb je nog zero-downtime. Dat bestaat eigenlijk niet, althans: niet in mijn beleving. Er zijn allerlei oplossingen die er voor kunnen zorgen dat het near-zero-downtime wordt, maar echt zero-downtime is schier onmogelijk. Wat Oracle de maximum availlability architecture (MAA) noemt, een combinatie van standby databases en active-active clustering (oftewel: dataguard en RAC) komt hierbij in de buurt, maar zelfs daarbij is het niet compleet mogelijk om zonder downtime te werken. Oplossingen als mysql-cluster en mysql replicaties bieden in geen geval zero-downtime.

[Davio]

Natuurlijk bestaat zero-downtime niet; als er een wereldwijde electromagnetische puls is, heb je toch downtime.

De vraag is altijd hoe ver je wilt gaan om het zo dicht mogelijk bij 0 te krijgen? En dat antwoord verschilt best veel per case. Een internationale bank mag bijvoorbeeld bijna nooit down zijn, terwijl een internetshop met 3 aankopen per dag best een dag uit de lucht mag zijn.

[chime]

Davio schreef op woensdag 21 juli 2010 @ 10:56:
Natuurlijk bestaat zero-downtime niet; als er een wereldwijde electromagnetische puls is, heb je toch downtime.

De vraag is altijd hoe ver je wilt gaan om het zo dicht mogelijk bij 0 te krijgen? En dat antwoord verschilt best veel per case. Een internationale bank mag bijvoorbeeld bijna nooit down zijn, terwijl een internetshop met 3 aankopen per dag best een dag uit de lucht mag zijn.

Meestal is er toch op zijn minst downtime voor wat systeem-maintenance.
(Of je zou je systeem al moeten gaan ontdubbelen en hopen dat na een upgrade alles mooi terug gesynct wordt)

Maar banken werken in de weekends niet => die hebben dan dus vrij veel tijd voor systeem maintenance.

[Grijze Vos]

FragFrog schreef op dinsdag 20 juli 2010 @ 09:48:
[...]

Absoluut waar. Toch is het vrij snel zo dat je wel een database crash kan hebben terwijl je FS intact is, maar een intacte DB terwijl het onderliggende FS stuk is zie je niet zo snel. Ik heb zelf een stuk vaker te maken met DB crashes dan FS crashes, wellicht een overgeneralisatie maar ik gok dat dit voor meer mensen geldt

Ik heb met MySQL een paar keer een "crash" gehad, /var zat vol.
Met SQL Server heb ik werkelijk nog nooit iets meegemaakt.

[Davio]

chime schreef op donderdag 22 juli 2010 @ 09:18:
[...]


Meestal is er toch op zijn minst downtime voor wat systeem-maintenance.
(Of je zou je systeem al moeten gaan ontdubbelen en hopen dat na een upgrade alles mooi terug gesynct wordt)

Maar banken werken in de weekends niet => die hebben dan dus vrij veel tijd voor systeem maintenance.

Dat banken niet werken, betekent niet dat mensen geen zaken willen doen.

[ACM]

Grijze Vos schreef op donderdag 22 juli 2010 @ 10:54:
Ik heb met MySQL een paar keer een "crash" gehad, /var zat vol.
Met SQL Server heb ik werkelijk nog nooit iets meegemaakt.

Dus eigenlijk ben je gewoon een wanbeheerder, maar geef je de database daar de schuld van? Dat het crashte (of misschien nog steeds wel) bij een volle disk is zeker geen nette response, maar het is ook niet erg handig van je dat je die disk vol liet lopen. Hoe vaak heb je dat met SQL Server gedaan?

[Wolfboy]

Met een crash bij een volle disk mag je al blij zijn imho. Voor hetzelfde geld heb je direct een corrupte tabel bij het wegschrijven. Een crash bij een volle disk is niet netjes, maar imho wel geoorloofd. Dan ben je gewoon een prutser als beheerder imho

Wat ik serieuzer vind is dat ik bij MySQL meermaals gewoon crashes heb gehad door het uitvoeren van bepaalde queries. Een update die een andere tabel aanspreekt bijvoorbeeld geeft (of gaf, misschien is het inmiddels gefixt) bij MySQL 5.1 een segfault en volledige server crash. Het ding restart wel automatisch maar het is nog steeds erg triest dat zoiets niet op een nettere manier afgehandeld wordt.

De bug is closed, zal misschien gefixt zijn inmiddels: http://bugs.mysql.com/bug.php?id=39320

[ Voor 6% gewijzigd door Wolfboy op 22-07-2010 16:35 ]

[Grijze Vos]

ACM schreef op donderdag 22 juli 2010 @ 11:30:
[...]

Dus eigenlijk ben je gewoon een wanbeheerder, maar geef je de database daar de schuld van? Dat het crashte (of misschien nog steeds wel) bij een volle disk is zeker geen nette response, maar het is ook niet erg handig van je dat je die disk vol liet lopen. Hoe vaak heb je dat met SQL Server gedaan?

Oh, maar dat was ook niet voor mijn werk hoor, die MySQL database. Dat was gewoon een thuisbakkie met een kleine site erop die een niet-roterend apache log had. Ik ben overigens geen beheerder.

[Soultaker]

FragFrog en JaQ: het is gewoon Git hoor (of soms zelfs git) stelletje breezah's!