[MySQL] Waar templates bewaren?

Hoewel ik zelf Joomla gebruik zou ik het zelf gewoon laten zoals het is, dus als een stel files op de schijf. De reden hiervoor is eigenlijk vrij simpel. Als je een template maakt dan hoef je hem niet meer te updaten in je database. Je past hem aan je drukt f5 en voila het werkt.

Een database gebruik je in mijn ogen puur en alleen waar een database bedoelt voor is: het opslaan van data en niet de presentatie ervan.

[ Voor 3% gewijzigd door Webgnome op 19-10-2008 21:50 ]

vanuit een bepaald standpunt kan je templates ook als 'data' beschouwen, maar dat terzijde.

Qua performance zou het niet uit mogen maken: een fatsoenlijk DBMS kan iets dergelijks even goed cachen als je OS / filesystem.

pistole schreef op zondag 19 oktober 2008 @ 21:53:
vanuit een bepaald standpunt kan je templates ook als 'data' beschouwen, maar dat terzijde.

Qua performance zou het niet uit mogen maken: een fatsoenlijk DBMS kan iets dergelijks even goed cachen als je OS / filesystem.

Neemt niet weg dat ieder DBMS ook zelf weer hangt op een OS + filesystem en dus per definitie trager zal zijn dan datzelfde OS + filesystem los.

Het performance verschil zal minimaal zijn, dus stel jezelf de vraag: Wat zijn de voordelen en wat zijn de nadelen? Zet de antwoorden daarop onder elkaar en maak een keuze.

Ik zie er zelf niet zoveel voordelen in om het in de database te stoppen eigenlijk?

Ik mis dus in je TS wat je zelf al verzonnen hebt? Dan kunnen wij het wel aanvullen of onze eigen mening geven.

Het is toch zo specifiek voor jouw situatie dat er weinig algemeens over te zeggen is.

[ Voor 11% gewijzigd door Verwijderd op 19-10-2008 21:58 ]

Verwijderd schreef op zondag 19 oktober 2008 @ 21:57:
[...]Neemt niet weg dat ieder DBMS ook zelf weer hangt op een OS + filesystem en dus per definitie trager zal zijn dan datzelfde OS + filesystem los.

Ik zie er zelf niet zoveel voordelen in om het in de database te stoppen eigenlijk?

Dezelfde voor- en nadelen die je zal hebben wanneer je binaire data in je database stopt.

Het is toch zo specifiek voor jouw situatie dat er weinig algemeens over te zeggen is.

dat, en het valt onder "smaak" en "stijl"

Wat hierbij natuurlijk ook meespeelt is of je iedere pagina bij iedere load weer opnieuw opbouwt vanuit je templates, of dat je hem eenmalig opbouwt en cached op schijf en vervolgens alleen opnieuw laat genereren bij wijzigingen in de pagina?

pistole schreef op zondag 19 oktober 2008 @ 22:03:
[...]

offtopic:
oneens maar niet relevant.

Zet dan DM aan zodat we er los over kunnen praten want ik vraag me toch sterk af waarom je het hier oneens mee bent.

Een DBMS draait simpelweg als applicatie op een OS en heeft dus per definitie overhead bovenop dit OS zelf. Door enkel te bestaan is er al overhead, hoe minimaal dat ook mag zijn.

Het lijkt me erg onhandig om templates niet direct in mijn favoriete editor te kunnen editen, hoe los je dit op? Per template via een fileupload ofzo opslaan lijkt me erg omslachtig.

Veel database calls zijn opzich niet erg, maar zorg dan voor goede caching. Fullpage caching werkt erg effectief. Je kunt bijv. heel simpel Zend_Cache inbakken uit het Zend Framework pakken. Je kunt gewoon n verlooptijd opgeven eraan of handmatig je cache legen bij updates oid.

> DTE

Als ik templates gebruik, dan is dat met Smarty, en laat ik het gewoon fysieke bestanden zijn. Hierdoor kun je er veel makkelijker mee werken. Anders moet je wijzigingen handmatig doorvoeren in de database.

Reveller schreef op maandag 20 oktober 2008 @ 08:55:
[...]

Wat zijn die nadelen dan? Ik heb zelf documenten (waaronder templates en plaatjes) altijd buiten de database opgeslagen, voornamelijk omdat de MySQL database anders zo groot wordt, en je ook al je documenten kwijt bent als de database corrupt zou raken. Wie van jullie slaat alles op in een database?

Ik gebruik een combinatie van macromedia dreamweaver/contribute en een eigen cms, contribute zet alle content gewoon op het fs neer, templates worden door contribute toegepast op html files, er vind dus geen request time parsing plaats ( php code wel uiteraard).

voor een recent project heb ik er bewust wel voor gekozen om alle afbeeldingen voor de producten in postgres te duwen, en dit bevalt erg goed. Dat je database groot wordt maakt niet uit, daar is het ding voor. Het zal mij persoonlijk een rotzorg zijn op er 10Gb in /www of in /var/db staat . zolang de performance maar goed is, en dat is absoluut geen probleem. database corrupt raken is uberhaubt is wat met postgres nooit gebeurd , maar daarvoor heb je uiteraard backups, dat heb je ook nodig voor als je data plat of het FS staat.

Ik zie nog niet echt een groot aantal voordelen waarom het in een database zou moeten ipv een simpele string naar de file in de db (eventueel)

Webgnome schreef op maandag 20 oktober 2008 @ 09:47:
Ik zie nog niet echt een groot aantal voordelen waarom het in een database zou moeten ipv een simpele string naar de file in de db (eventueel)

Omdat die methode nooit integriteit af kan dwingen, je hebt relatief veel werk van het in sync houden van je db en je filesystem. Als je een product weg wil gooien, en je komt er dan achter dat je geen rechten hebt om het laatste bestand te verwijderen, wat dan ?

[ Voor 13% gewijzigd door Kettrick op 20-10-2008 10:35 ]

Ik denk persoonlijk dat je op de eerste plaats moet doen wat je zelf het gemakkelijkst vindt. De tijd die je in een discussie als deze steekt krijg je er nooit qua performanceverschil eruit gehaald.

Op de tweede plaats: als je het echt wil weten: meten. Dat is echt de enige manier om erachter te komen wat het snelste werkt. (Als dat tenminste je 'eis' is).

Wat ik zelf meestal doe is bekijken wat voor 'gegevens' het zijn: ik kan me goed voorstellen dat je productafbeeldingen in een database opslaat, aangezien het ook echt een 'eigenschap' is van het domeinobject product. Qua 'in sync' houden kan ik me die keuze dan ook goed voorstellen. (Desalniettemin sla ik uit gemakzucht meestal het bestand gewoon op het filesystem op. Gaat misschien in MS SQL2008 wat gemakkelijker, die krijgt support hiervoor).

Bij templates gaat het naar mijn mening echter naar (vrij' statische bestanden, die over het algemeen geen relatie hebben met de 'data' uit je probleemdomein. Het betreft enkel de presentatie van die data. Daarom zou ik deze altijd gewoon op het FS opslaan, net zoals je je PHP-bestanden (of andere scriptbestanden) normaal fysiek opslaat.
(Afhankelijk van je manier van werken is versiebeheer dan ook wat gemakkelijker: enerzijds maak je backups van de database (de data), anderszijds kun je ook per versie van de site terug (de view).

Toevallig had ik hier van de week een blogpost over geschreven, naar aanleiding van een topic waarin mensen afbeeldingen in hun DB wilden opslaan.

Nog toevaliger is dat een RAID5 array het volledig begeven heeft (2 dode disks op een 3-disk array) waardoor het artikel niet beschikbaar is aangezien ik nog niet toegekomen ben aan het recoveren van de MySQL databases (geen productiedata en momenteel erg weinig tijd over). Al m'n templates staan echter op het filesystem en die werken allang weer.. I'm just saying

Er zijn enkele fundamentele verschillen tussen het opslaan van plaatjes in je DB en het opslaan van templates in je DB.

1. Plaatjes worden als aparte request opgehaald. Je zou er niet bij stil staan, maar hierdoor zijn plaatjes, in tegenstelling tot templates, inherrent veel langzamer middels een DB dan templates. De reden is simpel: als een request plaatsvind zal je webserver eerst een PHP bestand moeten laden, welke weer includes heeft, geparsed moet worden, een DB connectie moet openen (danwel eentje uit de connection pool halen), een SQL request moeten sturen, via een netwerk connectie data van de DB moeten ontvangen en vervolgens deze weer uitpoepen.

Als je plaatjes als statische files hebt moet je webserver 1 statische file openen - en klaar. No matter hoe goed je DB cache is, 1 bestand openen is altijd sneller dan minimaal 1 openen en vervolgens een zut SQL en parsing erna doen.

Voor een template geldt dit echter allemaal niet; een template kan makkelijk geladen worden met de rest van je script, dat betekend effectief dat je een file access actie verruild voor een database request. Welke dan sneller is hangt af van een enorme berg factoren, maar merkbaar veel verschil verwacht ik eigenlijk niet. Bovendien zijn dit slechts enkele requests per pagina, in tegenstelling tot plaatjes waarvan de gemiddelde website er enkele tientallen per pageview nodig heeft.

2. Hoe ga je plaatjes direct in je DB aanpassen? Is er uberhaupt iemand op deze planeet die met een hexeditor direct de bytecode van een image aan zal passen? Nee, dat gebeurt met externe programma's. Ja, het is mogelijk in diverse scripttalen om plaatjes te genereren, maar als ik kan kiezen tussen GD en photoshop hou ik het toch bij photoshop. Met uitzondering van server-generated images (grafieken, status data, etc) zit je er altijd aan vast dat je een bestand hebt in je filesystem wat je eerst naar je server upload en daarna importeert in je DB, om'm vervolgens bij een request weer te exporteren uit je DB en als file aanbied aan je client. Wat is dan het nut van die omweg naar je DB?

Maar dan: templates. Zijn bijna altijd wel direct in de bron te bewerken, hebben baat bij een goede zoek- en indexeerfunctie en bovendien kan het goed voorkomen dat je bepaalde delen van template A ook gebruikt in template B. Middels een database kun je dat prima koppelen en bijhouden, met alle nuttige functies die een DB biedt voor zoeken, indexeren en beheren erbij.

Conclusie: templates in je DB is (in tegenstelling tot binary data) absoluut geen slecht idee. Een van de meest bekende forum paketten, vBulletin, doet het ook bijvoorbeeld. Qua snelheid zal het geen merkbare impact hebben en qua beheerbaarheid zul je zelf de afweging moeten maken of je liever je eigen editor gebruikt of liever overal on-the-fly dingen aan wilt kunnen passen. Hou er wel rekening mee dat je een bewerktool zal moeten schrijven waardoor het wel meer werk is, vraag jezelf af of de voordelen daar tegen op wegen.

Voor mij persoonlijk is het antwoord op die vraag nee. Ik gebruik sowieso doorgaans Smarty, die mooi de templates in een voor designers begrijpelijk formaat omzet naar gecachde PHP code, een systeem wat meer dan uitstekend werkt. Bovendien zijn de statische template bestanden een stuk makkelijker in source control te gooien dan wanneer we zelf een dergelijk systeem zouden moeten maken gebasseerd op de DB. Aan de andere kant is een zelfgeschreven systeem, als het eenmaal werkt, veel simpeler aan te passen en uit te breiden dan wanneer je iets als SVN gebruikt. Al met al kan ik alleen maar zeggen: weet waar je aan begint, then make up your own damn mind

Smarty laat het trouwens wel toe om een eigen template source / template 'file system' te implementeren waardoor je aan de hand van paden zelf een database request kan maken. Hiermee wil ik alleen maar even zeggen dat als je Smarty wil gebruiken dat dat nog steeds kan met templates in de DB.

In de DB kan je de boel veel netter beheren, en je maakt toch al gebruik van de DB, het is geen extra (eventueel PHP) request zoals hierboven al geschreven werd.
Dat beheer voordeel geld trouwens ook voor plaatjes. Mocht je plaatjes willen laten zien op basis van rechten etc, dan kan je dat met een DB mooi regelen. Met plaatjes in een direcotry moet je juist de boel extra beveiligen en andere oplossingen (vaak buiten PHP om) in elkaar knutselen.
Nou moet ik zeggen dat ik nog niet met zo'n situatie om heb hoeven gaan, bij mij was het plaatjes meestal gewoon koppelen aan het juiste item en alleen dingen zoals dynamisch resizen en cachen, geen rechten gebeuren.

Als je een beetje serieus aan het ontwikkelen bent, maak je gebruik van versiebeheer met bijvoorbeeld CVS of Subversion. Een database is dan simpelweg geen optie.

Als je je templates in je versiebeheer systeem wil hebben niet nee. En dat is natuurlijk een hele logische keuze. Dan moet je dingen handmatig backuppen in je versie beheer systeem door ze even uit de DB te kopieren, erg omslachtig. En gaat voorbij aan het makkelijke van Subversion. (even klikken op Commit of Update)