PDF files opslaan in een MySQL database.

[MasterTweaker]

Ik vraag mij af of het gebruikelijk is om in een MySQL database gehele PDF files in binary formaat op te slaan? Neem bijvoorbeeld aan dat je een tabel genaamd: "Book" in je database hebt zitten. Deze tabel heeft de volgende kolommen:

ISBN
Naam schrijver:
Aantal bladzijde
Source code (Dit is dus de binary source code).

Nu zou ik dus in de kolom "Source code" de binary code willen opslaan van een gehele PDF file. Ik weet wel dat MySQL hier het "Blob" dataformaat voor aanbiedt:

A BLOB is a binary large object that can hold a variable amount of data. The four BLOB types TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB differ only in the maximum length of the values they can hold.

Maar nu is dus mijn vraag of dit gebruikelijk is en of dit gepaard kan gaan met forse performance problemen?

[dev10]

Je kunt beter complete bestanden opslaan in een database die daarvoor bedoeld is, namelijk het bestandssysteem. Je ontdaan in je database een verwijzing naar het bestand opslaan.

[Mr_gadget]

Over het algemeen is het gebruikelijker alleen meta informatie op te slaan in de DB. En dat je gewoon in een map met pdf's de pdf kan openen met idnummer.pdf bijvoorbeeld.

[MasterTweaker]

dev10 schreef op zondag 27 mei 2012 @ 16:42:
Je kunt beter complete bestanden opslaan in een database die daarvoor bedoeld is, namelijk het bestandssysteem. Je ontdaan in je database een verwijzing naar het bestand opslaan.

Oh ja natuurlijk dan heb je bijvoorbeeld een kolom in het formaat CHAR met het adres van de PDF file ( die ergens op een server staat):
C/:server123/1234/book.pdf

Dat lijkt mij inderdaad een stuk efficiënter, maar het is dus niet zo dat de manier die ik aandraag niet mogelijk is en je hiermee ernstige performance problemen krijgt?

[mhaket]

Stom vraag: wat is de rationale om de PDF niet in de DB op te slaan zoals alle voorgangers aandragen? Diskspace lijkt me niet de reden (drive kost ook ruimte). Backup, idem.

[MasterTweaker]

mhaket schreef op zondag 27 mei 2012 @ 16:53:
Stom vraag: wat is de rationale om de PDF niet in de DB op te slaan zoals alle voorgangers aandragen? Diskspace lijkt me niet de reden (drive kost ook ruimte). Backup, idem.

Waarschijnlijk zal je toch wel wat in moeten boeten qua performance. Omdat een SQL querrie waarschijnlijk langzamer werkt dan een "besturingssysteem call" naar een bestand. Maar goed dit weet ik dus niet geheel zeker.

[CH4OS]

MasterTweaker schreef op zondag 27 mei 2012 @ 16:48:
[...]

Oh ja natuurlijk dan heb je bijvoorbeeld een kolom in het formaat CHAR met het adres van de PDF file ( die ergens op een server staat):
C/:server123/1234/book.pdf

Dat lijkt mij inderdaad een stuk efficiënter, maar het is dus niet zo dat de manier die ik aandraag niet mogelijk is en je hiermee ernstige performance problemen krijgt?

Hoeft niet eens het pad op te slaan in de database. Je kan toch een vaste plaats bepalen waar de PDF's staan, bijvoorbeeld op ID-nummer? Dan is het pad elke keer hetzelfde, het ID is dan anders, die parse je dan mee in de URL en klaar. De manier die je aandraagt is zeker mogelijk, maar zal op den duur performance issues gaan opleveren. Daarnaast heeft ook BLOB een limiet, waardoor je wellicht niet elk document in de database op kan slaan. Bij een (modern) bestandssysteem heb je deze limieten niet met daar nog eens betere performance bij.

MasterTweaker schreef op zondag 27 mei 2012 @ 16:57:
Waarschijnlijk zal je toch wel wat in moeten boeten qua performance. Omdat een SQL querrie waarschijnlijk langzamer werkt dan een "besturingssysteem call" naar een bestand. Maar goed dit weet ik dus niet geheel zeker.

Bij deze: correcte mundo!

[ Voor 15% gewijzigd door CH4OS op 27-05-2012 16:58 ]

[mhaket]

Heeft iemand een onderbouwing voor dat performance verhaal? Iedereen roept het wel maar ik ben nog nergens en goede test tegen gekomen die dit bevestigd. Kan me niet voorstellen dat een extra tabel met een PK en een BLOB een performance verlies gaat opleveren voor de rest van de DB. Maar ik laat me graag overtuigen van het tegendeel

[Gomez12]

MasterTweaker schreef op zondag 27 mei 2012 @ 16:48:
[...]
Dat lijkt mij inderdaad een stuk efficiënter, maar het is dus niet zo dat de manier die ik aandraag niet mogelijk is en je hiermee ernstige performance problemen krijgt?

Totaal afhankelijk van het db.

Maar over het algemeen is het handiger om grote binaire blobs extern op te slaan. Zodat je het kan verdelen over meerdere servers etc ipv dat je een db van 20Gb loopt rond te sleuren qua backups etc.

Jouw voorgestelde opslagmethode zou ik afwijzen, maar dat is puur vanwege het feit dat je extra data op gaat slaan naast de binaire data. Dat vind ik niet al te handig.

Als je het in de db zou willen opslaan ipv op het FS dan zou ik zeggen maak een losse tabel aan met binaire data met enkel :
- een sleutel van de hash van de data
- Een kolom met de binaire data.

Zodat je nog steeds kan ontdubbelen zonder in de knoei te komen met metadata etc. Zodat je nog steeds kan sharden etc. Enkel heb je dan nog steeds ietwat extra overhead (db gaat ook nog steeds naar FS dus ten alle tijden heb je overhead)

mhaket schreef op zondag 27 mei 2012 @ 16:53:
Stom vraag: wat is de rationale om de PDF niet in de DB op te slaan zoals alle voorgangers aandragen? Diskspace lijkt me niet de reden (drive kost ook ruimte). Backup, idem.

Zolang je het in de DB op dezelfde manier gaat opslaan als op het FS dan lijkt het me geen probleem (dus zonder meta-data etc, die komt allemaal in aparte tabellen etc)
Want dan heb je gewoon een soort van FS in je DB gebouwd die je nog steeds kan splitsen etc.

Ga je het echter met metadata opslaan (zoals TS voorstelt) dan ga je problemen krijgen met dubbele records met andere metadata etc etc.

In wezen heb ik zoiets van : iedereen moet het zelf weten, maar simpel gezegd DB levert extra overhead op, en als de verhouding binnen je DB iets wordt van 19/20 is binair dan vraag ik me af waar je mee bezig bent...
Er zijn imho een aantal redenen waarom je zou kunnen kiezen voor binaire data in je DB, maar daar zie ik TS er geen van noemen.

mhaket schreef op zondag 27 mei 2012 @ 17:01:
Heeft iemand een onderbouwing voor dat performance verhaal? Iedereen roept het wel maar ik ben nog nergens en goede test tegen gekomen die dit bevestigd. Kan me niet voorstellen dat een extra tabel met een PK en een BLOB een performance verlies gaat opleveren voor de rest van de DB. Maar ik laat me graag overtuigen van het tegendeel

Simpel : Behalve als je in-memory table hebt dan zit je minimaal nog tegen het FS aan te praten. Dus je kan kiezen of je direct tegen het FS aan wilt praten of via een DB-laag (die intern ook weer tegen het FS aanpraat)

[CH4OS]

mhaket schreef op zondag 27 mei 2012 @ 17:01:
Heeft iemand een onderbouwing voor dat performance verhaal? Iedereen roept het wel maar ik ben nog nergens en goede test tegen gekomen die dit bevestigd. Kan me niet voorstellen dat een extra tabel met een PK en een BLOB een performance verlies gaat opleveren voor de rest van de DB. Maar ik laat me graag overtuigen van het tegendeel

Het is eigenlijk heel simpel: je hebt dan nog eens SQL er tussen zitten. Alle records worden met inhoud en al ook ergens naar toe weggeschreven en SQL zit daar dan als extra laag tussen. In het begin zal je weinig van performance loss merken, maar hoe groter je DB wordt (of hoe groter je records), hoe meer je het gaat merken, vooral op den duur dus.

[ Voor 38% gewijzigd door CH4OS op 27-05-2012 17:04 ]

[MasterTweaker]

Oke dus een verwijzing opslaan naar de locatie van het bestand is om performance redenen dus het effectiefst. Maar nu heb ik even een vraagje over de concrete toepassing hiervan. Stel je voor dat je database op een aparte databaseserver staat met daarop MySQL server geïnstalleerd.

Kan ik dan de boeken op dezelfde server plaatsen als de database? Of dien ik dan bijvoorbeeld Micorsoft Server 2008 te installeren op de databaseserver?

[StevenK]

CptChaos schreef op zondag 27 mei 2012 @ 17:03:
[...]
Het is eigenlijk heel simpel: je hebt dan nog eens SQL er tussen zitten.

Niet noodzakelijk: er zijn SQL engines die hun data raw naar een disk schrijven, zodat je juist niet de filesystem overhead hebt en daarmee kan een Blob in een table wel degelijk heel efficiënt zijn.

[CH4OS]

Ja, maar de meeste gratis RDBMS'en hebben daar geen support voor.

[GlowMouse]

mhaket schreef op zondag 27 mei 2012 @ 17:01:
Heeft iemand een onderbouwing voor dat performance verhaal? Iedereen roept het wel maar ik ben nog nergens en goede test tegen gekomen die dit bevestigd. Kan me niet voorstellen dat een extra tabel met een PK en een BLOB een performance verlies gaat opleveren voor de rest van de DB. Maar ik laat me graag overtuigen van het tegendeel

Je webserver kan veel sneller statische files serveren dan dynamische files. Bij dynamische files is het geheugen- en cpu-gebruik veel hoger.

[Verwijderd]

Naast echt als BLOB in RDBMS opslaan is het natuurlijk ook mogelijk de inhoud op te slaan als plaintext voor snellere access van de content. Ik gebruik hiervoor zelf meestal pdf2text of abiword voor.

Ook zijn er andere database engines als MongoDb die wel een out-of-the box oplossing hebben voor het opslaan van bestanden in een database.

[Hydra]

Gomez12 schreef op zondag 27 mei 2012 @ 17:02:
[...]

Totaal afhankelijk van het db.

Maar over het algemeen is het handiger om grote binaire blobs extern op te slaan.

Of je onderbouwt het, of je zegt gewoon niks? Nogmaals: komt met cijfers. Dat er een DB tussen zit zegt erg weinig. Een DB cached, het kan prima efficienter zijn zooi op te halen in 1 query dan het in een aparte call vanuit het FS op te halen. Komt nog eens bij dat je in multi-tier systemen over het algemeen gescheiden appserver en DB systemen hebt, dus vanuit de appserver vaak helemaal niet 'zomaar' het FS kan benaderen.

Dus: ik ben heel benieuwd wat het verschil is, en of dat uberhaupt significant is.

Verwijderd schreef op woensdag 30 mei 2012 @ 19:05:
Ook zijn er andere database engines als MongoDb die wel een out-of-the box oplossing hebben voor het opslaan van bestanden in een database.

Een beetje RDBMs ondersteunt ook gewoon BLOBs dus ik snap je "out of the box" punt niet zo.

GlowMouse schreef op zondag 27 mei 2012 @ 17:54:
Je webserver kan veel sneller statische files serveren dan dynamische files. Bij dynamische files is het geheugen- en cpu-gebruik veel hoger.

Als het puur en alleen om afzonderlijke files gaat kun je je proxy het alsnog prima laten cachen dus dat is het probleem ook niet.

[ Voor 33% gewijzigd door Hydra op 30-05-2012 20:10 ]

[Gomez12]

Hydra schreef op woensdag 30 mei 2012 @ 20:08:
[...]
Of je onderbouwt het, of je zegt gewoon niks? Nogmaals: komt met cijfers.

Of je wordt realistisch, of je zegt gewoon niks?

Cijfers vallen er niet te geven zonder een benchmark op de daadwerkelijke machine of op zijn minst een gedetailleerde beschrijving van de machine en de gebruikte instellingen.
Ik kan je cijfers geven waarin het perfect werkt (100x sneller dan disk-access op dezelfde machine) maar ik kan je ook cijfers geven waarin het waardeloos werkt (10.000x langzamer dan disk-access op dezelfde machine).

Het is totaal afhankelijk van de setup. Als ik 50Mb pdf's wil gaan hosten en ik definieer een mysql-memory-size van 20Mb dan heb je een ramp. Definieer je een memory-size van 64Gb dan kan het wel weer beter werken.
Oftewel je kan een machine inrichten dat het snel of langzaam gaat. Als ik mijn web-server via een smb-koppeling naar de files laat gaan dan zal dit "langzamer" zijn als dat ik de 64Gb in mijn dbase-server gebruik als caching.

Echter grosso modo, bij de meeste budget-webhosters zal de file-toegang sneller zijn (voor grotere files) dan de db-toegang voor dezelfde data. Maar dat is simpelweg omdat de meeste default webhoster setups meer gericht zijn op grote binaire data via het FS dan via de DB.
Dat zegt echter niet dat het niet op een dedicated machine die getuned is voor dit doelwit het niet sneller zal zijn. Echter de meetresultaten zijn onmogelijk te geven zonder uitgebreide details en tuning-settings.

Maar laat ik het zo zeggen : Als jij je machine getuned hebt voor een db met grote binaire data dan stel je deze vraag zeer waarschijnlijk al niet meer aangezien je al metingen etc gedaan hebt voordat je begon te tunen.

Maar ik zou zeggen : Laat mij je niet tegenhouden om cijfers te publiceren die voor elke mysql-dbase met elke settings-file en op elke hw-config van toepassing zijn hoor. Ik kan ze niet produceren zonder extra info, maar als jij het wel kan?

[ Voor 12% gewijzigd door Gomez12 op 30-05-2012 20:47 ]

[synoniem]

Uit eigen ervaring weet ik dat het opslaan en teruglezen van een kleine collectie jpeg bestanden als blob in mysql behoorlijk wat cpu tijd vroeg. Nadat ik ze liet cachen op de webserver scheelde dat aanzienlijk. Maar goed dat was inderdaad bij een budget hoster met een redelijk standaardconfiguratie.

[JaQ]

MasterTweaker schreef op zondag 27 mei 2012 @ 16:40:
Maar nu is dus mijn vraag of dit gebruikelijk is en of dit gepaard kan gaan met forse performance problemen?

Is performance je enige relavante vraag? Of ben je ook op zoek naar mogelijkheden om consistente backups te maken van je metadata en bestanden? (ik denk dan aan point in time recovery).

[Ventieldopje]

Volgensmij slaat MySQL binaire blobs altijd op als aparte bestanden voor zover ik weet. Ik zou toch voor een file-system gebaseerde aanpak gaan. Een stuk makkelijker te beheren en te backuppen (je kunt immers bij je bestanden en dat is van een DB niet te zeggen).

Naast dat kun je ook makkelijk en snel checksums van je bestanden maken, ze desnoods encrypten of op een hele andere pc zetten dmv. bijvoorbeeld NFS.

[JaQ]

Ventieldopje schreef op woensdag 30 mei 2012 @ 20:57:
Een stuk makkelijker te beheren en te backuppen (je kunt immers bij je bestanden en dat is van een DB niet te zeggen).

Backups van filesystem zijn typisch tijd gedreven (zeg eens per dag of zo), waar backups van databases typisch transactie gedreven zijn (binary logs heten die dingen in mysql als ik mij niet vergis).

Persoonlijk denk ik dat een restore-mogelijkheden tot op transactie een hogere granulariteit hebben, vind jij van niet?

[Gomez12]

JaQ schreef op woensdag 30 mei 2012 @ 21:09:
[...]

Backups van filesystem zijn typisch tijd gedreven (zeg eens per dag of zo), waar backups van databases typisch transactie gedreven zijn (binary logs heten die dingen in mysql als ik mij niet vergis).

Persoonlijk denk ik dat een restore-mogelijkheden tot op transactie een hogere granulariteit hebben, vind jij van niet?

Geneuzel in de marge zolang je niet een speciale setup ervoor hebt.

Transactie logs zijn (afaik) zo goed als altijd inpandig. En worden pas bij filesystem backup procedure uitpandig gehaald. Oftewel bij een brand heb je nog steeds enkel maar de filesystem backup (die dan weer de transactie logs bevat tot het tijd-gedreven punt)

Imho is een tijd gedreven backup enkel noodzakelijk voor fysieke beschadigingen (vuur / aardbeving / aliens die landen) waardoor je de uitpandige backup nodig hebt.

Inpandige backups zijn op vele andere manieren te doen dan enkel tijd gedreven

[JaQ]

Gomez12 schreef op woensdag 30 mei 2012 @ 21:34:
Imho is een tijd gedreven backup enkel noodzakelijk voor fysieke beschadigingen (vuur / aardbeving / aliens die landen) waardoor je de uitpandige backup nodig hebt.

En hoe ga je dan om met een user die "per ongeluk" files weggooit? Of een admin die e.e.a. verwijderd?

Gomez12 schreef op woensdag 30 mei 2012 @ 21:34:
Inpandige backups zijn op vele andere manieren te doen dan enkel tijd gedreven

Absoluut, maar ook als je die consistent wilt hebben met je metadata in je database? Zeker bij een hogere transactiegraad wordt dat een lastig verhaal. Vervolgens ligt het er maar net aan hoe belangrijk je files zijn.

[Gomez12]

JaQ schreef op woensdag 30 mei 2012 @ 21:40:
[...]

En hoe ga je dan om met een user die "per ongeluk" files weggooit? Of een admin die e.e.a. verwijderd?

Welke user heeft daar de rechten voor? Users mogen soft-deletes doen en geen hard-deletes.
En een admin valt niet tegen te houden, die kan net zogoed de transactie logs verwijderen.

Laat ik het anders zeggen, op het moment dat ik een tape-backup ga gebruiken om bestandjes van een user (ipv systeem) te restoren dat is de dag dat ik iets grondig verkeerd doe. Dan dien ik liever een aanvraag in bij de directie voor een 3e en 4e SAN dan dat ik backups ga restoren voor 1 user.

Als je bang bent voor users die "per ongeluk" files deleten dan mag je van mij een ethernet hdd in het netwerk hangen voor xxx euro die een continu robocopy uitvoert. xxx euro is nog altijd goedkoper als ik die uit een backup even 2 bestandjes voor 1 user moet terugzetten (dat schept namelijk een precedent)

[JaQ]

Gomez12 schreef op woensdag 30 mei 2012 @ 21:56:
Welke user heeft daar de rechten voor? Users mogen soft-deletes doen en geen hard-deletes.

Je komt de gekste dingen tegen, zeker in systemen die je aanschaft ipv zelf ontwikkelt (maar niet van toepassing in de vraag van de TS. Daar heb je gelijk in)

Gomez12 schreef op woensdag 30 mei 2012 @ 21:56:
En een admin valt niet tegen te houden, die kan net zogoed de transactie logs verwijderen.

Omgekeerde logica, geen argument. Beheerders vergeten ook om tapes te verwisselen, zetten firewalls tussen netwerkverbindingen naar het offsite datacenter, negeren SMART meldingen, etc. etc.

Gomez12 schreef op woensdag 30 mei 2012 @ 21:56:
Laat ik het anders zeggen, op het moment dat ik een tape-backup ga gebruiken om bestandjes van een user (ipv systeem) te restoren dat is de dag dat ik iets grondig verkeerd doe. Dan dien ik liever een aanvraag in bij de directie voor een 3e en 4e SAN dan dat ik backups ga restoren voor 1 user.

Als je bang bent voor users die "per ongeluk" files deleten dan mag je van mij een ethernet hdd in het netwerk hangen voor xxx euro die een continu robocopy uitvoert. xxx euro is nog altijd goedkoper als ik die uit een backup even 2 bestandjes voor 1 user moet terugzetten (dat schept namelijk een precedent)

Het hangt allemaal erg af van de belangrijkheid van je data, zeker in combinatie met wettelijke eisen. Goedkope oplossingen met netwerk diskjes en oplossingen met Windows tooling als robocopy zijn dan aardig, maar zeker niet afdoende. De vraag van de TS klinkt echter niet alsof het om echt heel erg belangrijke data gaat.

Hoe dan ook, persoonlijk zou ik voor een systeem altijd voor de eenvoudigste restore-optie kiezen. m.i. is dat alles in de database (dan hoef je nooit metadata met filesystem te vergelijken, ik zou je veel succes wensen als je een groot aantal bestanden moet vergelijken met metadata). Als je al performance verliest door opslag in een database, dan vind ik dat makkelijk opwegen tegen het beheergemak. Daarbij moet ik wel opmerken dat ik met Oracle databases werk ipv MySQL (en op systemen die wel PITR vereisen vanuit EU of DNB regels).

[Gomez12]

JaQ schreef op woensdag 30 mei 2012 @ 22:15:
[...]
Hoe dan ook, persoonlijk zou ik voor een systeem altijd voor de eenvoudigste restore-optie kiezen. m.i. is dat alles in de database
...
Daarbij moet ik wel opmerken dat ik met Oracle databases werk ipv MySQL (en op systemen die wel PITR vereisen vanuit EU of DNB regels).

Nou weet ik niet hoe oracle opslag werkt. Maar transactie logs wil je meestal maar van een "korte" periode bewaren en daarna wil je een complete backup hebben.

Qua restore opties zet ik liever 100.000 files terug waarvan er misschien vanwege reden x/y/z 10 beschadigd zijn dan 10 db-files van 10Gb het stuk waarvan er 1 beschadigd is.

Persoonlijk moet ik er niet aan denken om bij een restore actie een initiele database te restoren en dan daarna 5 jaar aan transactie logs daaroverheen te gooien. Maarja, ik moet er ook niet aan denken om 1 db van 200Gb te moeten restoren om er dan achter te komen dat murphy's law heeft opgetreden.
Doe mij dan maar 1 db van 5Gb met daarnaast 195Gb aan files waarbij murphy's law optreedt in 10 files.

Oftewel het blijft een afweging. Heb je de structuur in huis om elke dag echt de backup te controleren zodat je murphy's law minimaliseert (desnoods pak je de backup van gister) dan kan 1 db van 200Gb best acceptabel zijn. Mis je echter de dagelijkse controle (imho bij 99% van de bedrijven van toepassing) of je de backup ook echt kan restoren dan is het een riskante operatie en kan je murphy weer minimaliseren door simpelweg de kans dat murphy iets belangrijks raakt te minimaliseren.

Zo ken ik nog een "grappig" verhaal van een ex-collega van mij. Die had een "defecte" backup drive en een strict backup + restore regime zodat hij altijd 100% zeker wist dat het te restoren was. Met de "defecte" drive ging het helemaal perfect, jarenlang goed gegaan. Toen kwam er een nieuwe server + een nieuwe tape-robot en spontaan kwamen er allemaal errors naar boven (tijdens backup en restore).
Hij heeft er ongeveer een maand in gestoken (inclusief HP-hulp) en eindconclusie was : zijn oude tape-drive was niet up-to-spec maar functioneerde wel binnen zichzelf. As in alles wat beschreven werd was ook weer uit te lezen, alleen niet in een andere tape-robot, enkel in dit ene apparaat wat off-spec was.

Dit soort verhalen zijn grappig zolang ze ontdekt worden bij vervanging server etc. Komen ze naar boven terwijl je server net afgefikt is en je een bedrijfs-restore op een complete nieuwe bak probeert te doen dan zijn ze iets minder grappig.

En in dat licht vind ik het ook altijd wel grappig hoe sommige mensen netwerk-diskjes etc afschrijven als "voor ongevoelige data" etc. Hetgene wat er op die dingen staat is namelijk ook niet-gevoelige data. Die dingen kunnen 10x per jaar kapot vallen, de echte belangrijke backup is wel netjes geregeld, het enige wat die dingen doen is een stukje restore-beheer weghalen zodat alledaagse users het zelf kunnen ipv dat sys-beheer het moet doen.

[ Voor 45% gewijzigd door Gomez12 op 30-05-2012 22:51 ]

[Hydra]

Gomez12 schreef op woensdag 30 mei 2012 @ 20:37:
Of je wordt realistisch, of je zegt gewoon niks?

Jij loopt te beweren dat er een significant verschil is, dan kun je dat toch aantonen? Het is onzin dat je dat voor elk systeem zou moeten doen; als je het voor een gemiddeld systeem aan kunt tonen dat het storen in een DB significant trager is, dan heb je het tenminste aannemelijk gemaakt. Jij hebt kennelijk geen zin daar moeite in te steken, prima, maar beweer dan niet zo stellig dat het op disk opslaan beter is. Ik geloof best dat er in het geval van MySQL specifiek wat extra overhead is. Maar of dat significant is, dat is de vraag.

Het enige goeie antwoord op de vraag van de TD is namelijk dat het afhankelijk is van de architectuur en de requirements, maar dat het in zijn geval (simpel webapplicatietje) waarschijnlijk geen fluit uitmaakt en hij gewoon moet gaan voor de oplossing die het meest straightforward voor hem is. Mocht z'n site opeens een doorslaand succes worden dan zal 'ie waarschijnlijk toch naar een andere oplossing moeten gaan kijken dan die zooi opslaan op z'n shared webservertje

[Gomez12]

Hydra schreef op donderdag 31 mei 2012 @ 12:55:
[...]
Jij loopt te beweren dat er een significant verschil is

Ik houdt het maar op een miscommunicatie, volgens mij schreef ik nergens iets over significant verschil, maar als jij het erin las...

[Hydra]

Gomez12 schreef op donderdag 31 mei 2012 @ 13:01:
Ik houdt het maar op een miscommunicatie, volgens mij schreef ik nergens iets over significant verschil, maar als jij het erin las...

Ik ging er vanuit dat als we het over verschillen hebben dat het danook significante verschillen zijn, onder het mom van "premature optimization is the root of all evil" zegmaar