[PHP] Templates in de database

[Spixo]

Op dit moment run ik een kleine site met zo ongeveer 50 visitors per dag. Het geheel draait nu op TemplatePower. Zit er echter over na te denken om de templates voortaan in de database op te slaan. Alleen ben nog niet helemaal zeker.

Voordelen:
- Met een admin kan ik de templates rechtstreeks in de database bewerken
- Minder bestanden in de FTP

Nadelen:
- Mogelijk trager?
- Als MySQL down is is de site ook down

Ik kan niet echt een keuze maken, wat hebben jullie?

[Verwijderd]

Ik gebruik ook template power, nu nog, maar ik denk dat ik er vanaf stap en PHP zelf als template engine ga gebruiken. Als je templatePower gebruikt zou ik niet alle templates in je DB zetten. De voordelen die je noemt, vind ik zelf geen voordelen.
Wat maakt het uit of je veel bestanden op je FTP account heb staan? Je kan de templates ook direct op de server bewerken m.b.v. een bewerkprogramma dat meteen op de ftp kan werken. EditPlus of een andere editor.
Kortom, je voordelen die je opnoemt, vind ik geen voordelen.

[Spixo]

Verwijderd schreef op zondag 26 december 2004 @ 17:03:
Ik gebruik ook template power, nu nog, maar ik denk dat ik er vanaf stap en PHP zelf als template engine ga gebruiken. Als je templatePower gebruikt zou ik niet alle templates in je DB zetten. De voordelen die je noemt, vind ik zelf geen voordelen.
Wat maakt het uit of je veel bestanden op je FTP account heb staan? Je kan de templates ook direct op de server bewerken m.b.v. een bewerkprogramma dat meteen op de ftp kan werken. EditPlus of een andere editor.
Kortom, je voordelen die je opnoemt, vind ik geen voordelen.

Mag ik vragen wat de reden is dat je van TemplatePower afstapt?

[simon]

Ik vind je tegens eerlijk gezegd niet echt top. Je kan ze net zo goed met php editen zonder dat je daar een DB voor nodig hebt..

[Spixo]

Simon schreef op zondag 26 december 2004 @ 17:06:
Ik vind je tegens eerlijk gezegd niet echt top. Je kan ze net zo goed met php editen zonder dat je daar een DB voor nodig hebt..

Laat ik mijn vraag dan anders formuleren. Zijn er mensen die hun templates in een database opslaan, en waarom?

[Verwijderd]

Ricardo87 schreef op zondag 26 december 2004 @ 17:04:
[...]

Mag ik vragen wat de reden is dat je van TemplatePower afstapt?

Waarom een template engine gebruiken, terwijl PHP zelf een grote template engine is
Ik denk dat we hier discusie "PHP wel of geen template engine" niet gepast is. Die discussie is hier al tot in den treure behandeld. Je algemenere vraag: "Zijn er mensen die templates in de database opslaan", vind ik een goed onderwerp voor discussie.

Ik sla mijn templates niet op in de database. Niet de complete template, maar soms wel bepaalde data die in de template ingevuld moet worden; titel, tekst, subtitel, whatever...
Ik zie niet in waarom je de complete template zelf ook in de DB zou (willen) opslaan.

[Spixo]

Verwijderd schreef op zondag 26 december 2004 @ 17:11:
[...]


Waarom een template engine gebruiken, terwijl PHP zelf een grote template engine is
Ik denk dat we hier discusie "PHP wel of geen template engine" niet gepast is. Die discussie is hier al tot in den treure behandeld. Je algemenere vraag: "Zijn er mensen die templates in de database opslaan", vind ik een goed onderwerp voor discussie.

Ik sla mijn templates niet op in de database. Niet de complete template, maar soms wel bepaalde data die in de template ingevuld moet worden; titel, tekst, subtitel, whatever...
Ik zie niet in waarom je de complete template zelf ook in de DB zou (willen) opslaan.

Om toch nog even terug te komen op het feit dat PHP zelf een template-engine is. Ik gebruik TemplatePower om mijn design totaal gescheiden te houden. Als je het gaat vermengen met je PHP code kan je daar altijd in gaan lopen vroeten bij een layout change.

Maargoed, iemand ervaring met database templates?

[Hans1990]

Ik zal het afraden om templates in de database op te slaan. De voordelen zijn niet echt 'voordelen' te noemen. Ik heb ook al adviesen van andere scripters gekregen over dit. Iemand zei dat een database een plek is om data op te slaan dat verandert. Ik denk niet dat je elke dag je templates gaat bewerken, dus het is een beetje vaste data. Dat kan je wel met gemak op de server neerzetten, en of er nou veel of weinig files op je server staan. Who cares, gewoon met mapje's werken en het lukt wel

Ricardo87 schreef op zondag 26 december 2004 @ 17:08:
[...]

Laat ik mijn vraag dan anders formuleren. Zijn er mensen die hun templates in een database opslaan, en waarom?

Ik heb het vroeger wel gedaan omdat het makkelijk was om zo een administratie ervoor te maken. Maar ik ben daar nu vanaf gestapt, het mag dan wel makkelijk zijn om een administratie te maken, maar een echte PHP-er gaat voor een uitdaging. En na een tijdje lukt het heus wel

[ Voor 36% gewijzigd door Hans1990 op 26-12-2004 17:34 ]

[Michali]

Ricardo87 schreef op zondag 26 december 2004 @ 17:14:
[...]

Om toch nog even terug te komen op het feit dat PHP zelf een template-engine is. Ik gebruik TemplatePower om mijn design totaal gescheiden te houden. Als je het gaat vermengen met je PHP code kan je daar altijd in gaan lopen vroeten bij een layout change.

Als die php code direct in vervand staat met de layout moet het hoe dan ook aangepast worden. Als je in je gescheide php code moet gaan wijzigen om puur iets in de layout te verdanderen, dan ben je fout bezig. Zet het dan bij elkaar, dat heeft heus niet zo veel nadelen. Verder kun je je logica en presentatie net zo netjes scheiden als met een losse template engine. Mischien zijn de php statements iets minder mooi, maar dat is gewoon smaak. En het heeft als nog een voordeel dat je geen overhead hebt van het parsen van de template. Het is gewoon een stuk sneller. Meer zeg ik er niet over anders loopt het weer uit de hand

[JaQ]

Hans1990 schreef op zondag 26 december 2004 @ 17:32:
Iemand zei dat een database een plek is om data op te slaan dat verandert. Ik denk niet dat je elke dag je templates gaat bewerken, dus het is een beetje vaste data.

Dat is natuurlijk een non argument. Dan zou je logfiles ook niet in een database gooien (veranderen die wel dan?) Of andere historische gegevens als valuta koersen, clicks van users etc. etc.

Ook down time van een database is een non argument. Als je kiest voor een setup met een single point of faillure, dan zou je die natuurlijk redundant uit kunnen voeren, oftewel: zorg dat je een slave database hebt. Het ligt er dus maar net aan hoe je het aanpakt.

Ik denk dat het enkel om persoonlijke voorkeur gaat. Of je een template nou op het filesystem zet of niet is volgens mij volledig onbelangrijk. Uiteindelijk gaat het erom wat je er mee doet. Het sterkste argument dat ik kan bedenken voor templates in je database is consequentie. dwz: alles zit in je database, dus alles spreek je op dezelfde manier aan. Dat is ook meteen het enige echte argument dat ik kan bedenken.

[Verwijderd]

Ricardo87 schreef op zondag 26 december 2004 @ 16:58:
Op dit moment run ik een kleine site met zo ongeveer 50 visitors per dag. Het geheel draait nu op TemplatePower. Zit er echter over na te denken om de templates voortaan in de database op te slaan. Alleen ben nog niet helemaal zeker.

Voordelen:
- Met een admin kan ik de templates rechtstreeks in de database bewerken
- Minder bestanden in de FTP

Nadelen:
- Mogelijk trager?
- Als MySQL down is is de site ook down

Ik kan niet echt een keuze maken, wat hebben jullie?

Templates in je DB gooien biedt volgens mij geen enkel voordeel boven gewoon je templates als bestanden aanhouden. Naar mijn idee is het ook veel trager om bij elke request een query uit te voeren dan een bestand te openen. Over de voor- en de nadelen:

- Met een admin kan ik de templates rechtstreeks in de database bewerken
Dit kan ook met "gewone bestanden", is dus geen voordeel
- Minder bestanden in de FTP
Zoals al vaak hierboven genoemd is ook dit geen voordeel volgens mij
- Mogelijk trager?
Veel trager om templates in db te gooien
- Als MySQL down is is de site ook down
Dat gebeurt wel vaker, dat een site down is als MySQL down is Denk aan CMS'en, fora, etc.

Nogmaals, het lijkt me echt geen enkel voordeel hebben om de templates in een db te gooien.

Edit: Je vraagt ook wat wij doen: Nou, voor als dat nog niet duidelijk was, ik gebruik dus gewoon bestanden

[ Voor 5% gewijzigd door Verwijderd op 26-12-2004 19:01 ]

[JaQ]

Verwijderd schreef op zondag 26 december 2004 @ 19:00:
[...]

- Mogelijk trager?
Veel trager om templates in db te gooien

met welk argument?

Volgens mij maakt het helemaal niet zo heel veel uit of je nou een file inleest vanaf je fs en dan parst, of dat je een rij inleest uit je database en dan parst. Of maak ik nou een denkfout?

edit:
ow.. ik gebruik overigens templates uit een database, maar dat komt door het CMS dat ik gebruik

[ Voor 13% gewijzigd door JaQ op 26-12-2004 19:06 ]

[Spixo]

Poll: Maken jullie gebruik van templates?
• Ja, met bestanden
• Ja, met de templates in de database
• Nee, ik gooi design en code door elkaar
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

[Spixo]

DrFrankenstoner schreef op zondag 26 december 2004 @ 19:05:
[...]


met welk argument?

Volgens mij maakt het helemaal niet zo heel veel uit of je nou een file inleest vanaf je fs en dan parst, of dat je een rij inleest uit je database en dan parst. Of maak ik nou een denkfout?

edit:

ow.. ik gebruik overigens templates uit een database, maar dat komt door het CMS dat ik gebruik

Volgens mij is het inlezen van een file langzamer dan het simpel selecteren van een record. (er vanuit gaande dat de database niet 500.000 records ofzo heeft).

p.s., welk CMS gebruik je?

[JaQ]

Ricardo87 schreef op zondag 26 december 2004 @ 19:12:
[...]

Volgens mij is het inlezen van een file langzamer dan het simpel selecteren van een record. (er vanuit gaande dat de database niet 500.000 records ofzo heeft).

p.s., welk CMS gebruik je?

een goed ontwikkelaars spreekwoord is: assumption is the mother of all fuck-ups

Anwyay, ik weet het ook niet zeker en daarom vraag ik er dus naar. Ik denk echter wel dat als je een wat slimmere database gebruikt (dus geen mysql, maar iets met een procedural language zoals bijvoorbeeld postgresql, sap of oracle) het voordeel misschien nog wel meer richting database gaat. (omdat je vaak toch rijen selecteerd en deze merged met je template)

Ik bied hosting aan i.c.m. midgard / aegir. Een cms dat eigenlijk alleen geschikt is voor mensen met php kennis. De kern van deze draak is de mogelijkheid van code snippets (stukken php dus) te kunnen delen tussen verschillende domeinen. Vooral als je zelf sites bouwd voor klanten is dit dus interessant [einde reclame]

[Verwijderd]

Ricardo87 schreef op zondag 26 december 2004 @ 19:12:
[...]

Volgens mij is het inlezen van een file langzamer dan het simpel selecteren van een record. (er vanuit gaande dat de database niet 500.000 records ofzo heeft).

p.s., welk CMS gebruik je?

Bij elk request een query.. Je zegt "simpel selecteren van een record", maar als je grote templates hebt.. En dan nog meerdere templates per pagina waarschijnlijk (header/nieuws/footer/etc). Lijkt me langzamer, maargoed dat moet je even testen dan.

Enne, dat laatste was niet op mij gericht, maar ik gebruik een eigen geschreven cms, met de template-engine tplphp van MisterData.

[Verwijderd]

Ricardo87 schreef op zondag 26 december 2004 @ 19:12:
[...]

Volgens mij is het inlezen van een file langzamer dan het simpel selecteren van een record. (er vanuit gaande dat de database niet 500.000 records ofzo heeft).

Als je langer dan 2 seconden nadenkt, weet je dat dit pure onzin is. Waar denk je dat een database zijn data bijhoudt? Inderdaad, in bestanden op de schijf! Of je nu je templates rechtstreeks uit de bestanden haalt, of via je database, je bent uiteindelijk in beide gevallen met bestanden bezig.

Een database is trager, omdat je een grotere omweg maakt om tot je data te komen. De kracht van een database zit hem niet in het snel inlezen van data (integendeel), maar het snel joinen/mergen van data/bestanden op basis van condities.

Aangezien dit laatste waarschijnlijk niet de bedoeling is (als ik het goed begrijp wil de TS zijn templates simpelweg kopiëren naar de database, en per pagina de overeenkomstige template/record neerhalen), is het antwoord heel simpel: neen, want:

1) het is trager
2) hiervoor zijn databases niet voor bedoeld

Simpel gezegd: als je data in je database gaat steken, en je maakt nergens gebruik van de 'kracht van databases tov. flat files' (indexing, joins, transactions, ...), ben je fout bezig.

Uitspraken als "er vanuit gaande dat de database niet 500.000 records ofzo heeft" houden echt geen steek.

[ Voor 19% gewijzigd door Verwijderd op 26-12-2004 19:40 ]

[JaQ]

Verwijderd schreef op zondag 26 december 2004 @ 19:31:
Als je langer dan 2 seconden nadenkt, weet je dat dit pure onzin is. Waar denk je dat een database zijn data bijhoudt? Inderdaad, in bestanden op de schijf! Of je nu je templates rechtstreeks uit de bestanden haalt, of via je database, je bent uiteindelijk in beide gevallen met bestanden bezig.

helemaal waar, maar dat heeft er niets mee te maken.

Verwijderd schreef op zondag 26 december 2004 @ 19:31:
Een database is trager, omdat je een grotere omweg maakt om tot je data te komen. De kracht van een database zit hem niet in het snel inlezen van data (integendeel), maar het snel joinen/mergen van data/bestanden op basis van condities.

ok: ik wil een pagina tonen:

1. open file handle
2. haal bestand (template) op
3. open database handle
4. haal data op
5. merge

(en uiteraard handles sluiten, maar die laat ik wel even achterwege in deze)

in het geval van database:
1. open database handle
2. haal data op
3. haal template op (= eigenlijk hetzelfde als stap 2)
4. merge

welke omweg? Je bedoeld dat de database ook in een bestand leest? helemaal waar, maar om een of andere reden werkt de core van een database (meestal C) iets sneller met files dan de core van je website (php in dit geval). Daarnaast heb je dan nog argumenten als security maar die doen er nu even niet toe. Je database kan overigens ook records cachen. In dit geval zit je template dus altijd in je cache, aangezien je de template records nogal vaak queried. En ra-ra waar zit je cache?

Verwijderd schreef op zondag 26 december 2004 @ 19:31:

Aangezien dit laatste waarschijnlijk niet de bedoeling is (als ik het goed begrijp wil de TS zijn templates simpelweg kopiëren naar de database, en per pagina de overeenkomstige template/record neerhalen), is het antwoord heel simpel: neen, want:

1) het is trager
2) hiervoor zijn databases niet voor bedoeld

het is trager zie ik dus niet, zeker niet als je alleen selecteerd. Dat mysql nou toevallig bizar slecht is in insert en update snelheid, wil niet zeggen dat een database dat ook is (mysql = flat file system in mijn optiek)

Verwijderd schreef op zondag 26 december 2004 @ 19:31:
Simpel gezegd: als je data in je database gaat steken, en je maakt nergens gebruik van de 'kracht van databases tov. flat files' (indexing, joins, transactions, ...), ben je fout bezig.

Uitspraken als "er vanuit gaande dat de database niet 500.000 records ofzo heeft" houden echt geen steek.

het aantal records in een database of tabel is inderdaad geen argument (daarom reageerde ik niet). Maar ongefundeerde uitspraken die je hier zelf maakt houden net zo min steek. Als je bijvoorbeeld meerdere templates beschikbaar wilt stellen aan een user (zie got layout), maak je dan geen join? ik noem maar wat....

Ik blijf er bij dat het volledig afhankelijk is van de willekeur / voorkeur van de programmeur en dat er geen goed of fout is in deze...

[Verwijderd]

DrFrankenstoner schreef op zondag 26 december 2004 @ 19:57:welke omweg? Je bedoeld dat de database ook in een bestand leest?

Als je data raadpleegt via een database, gaat je request (zeg maar je query "SELECT...") doorheen een heel aantal subsystemen (bijv. het parsen van je query, te gebruiken indexes bepalen, record/block offsets bepalen, buffers vastleggen, ...). Dit is allemaal niet het geval wanneer je bestanden rechtstreeks raadpleegt. Dit bedoel ik met omweg.

Het kan wel zijn dat een database het effectief inlezen van een bestand sneller kan (C tov. PHP, PS: PHP is ook C hoor ), maar een database doe o-zo-veel-meer dan alleen maar inlezen.

Je database kan overigens ook records cachen. In dit geval zit je template dus altijd in je cache, aangezien je de template records nogal vaak queried. En ra-ra waar zit je cache?

Heb ik dan ergens gezegd dat je met plain files niet meer kan cachen (in het geheugen)?

het is trager zie ik dus niet, zeker niet als je alleen selecteerd.

Probeer het dan eens uit, ipv. eerst te doen alsof je weet waarover je praat, maar daarna aan je eigen woorden gaat twijfelen.

Als je bijvoorbeeld meerdere templates beschikbaar wilt stellen aan een user (zie got layout), maak je dan geen join?

Akkoord, maar aangezien de TS hierover helemaal niet spreekt (cfr. zijn voor- en nadelen), ben ik van zulke situaties niet uitgegaan. Voor mij wil hij een database beschouwen als een handige ('minder bestanden', 'makkelijkere benadering') dataopslagplaats, hetgeen volledig verkeerd is.

[ Voor 3% gewijzigd door Verwijderd op 26-12-2004 20:25 ]

[JaQ]

Verwijderd schreef op zondag 26 december 2004 @ 20:25:

Heb ik dan ergens gezegd dat je met plain files niet meer kan cachen (in het geheugen)?
[...]

Akkoord, maar aangezien de TS hierover helemaal niet spreekt (cfr. zijn voor- en nadelen), ben ik van zulke situaties niet uitgegaan. Voor mij wil hij een database beschouwen als een handige ('minder bestanden', 'makkelijkere benadering') dataopslagplaats, hetgeen volledig verkeerd is.

cachen kan idd ook van files, daar heb je gelijk in. Ook de subsystemen die gebruikt worden heb je gelijk in (alhoewel je voor het ophalen van files over het algemeen ook voorgedefineerde functies gebruikt, maar dat terzijde)

Overigens roep ik vanaf mijn eerste post in dit topic dat ik denk dat het aan de willekeur / voorkeur ligt van de programmeur en dat het enige echte voordeel van een database consiquentie is (alles uit database halen ipv gedeelte database, gedeelte filesystem). Dat argument blijf ik ondersteunen. Dat is dus iets anders dan hard roepen dat een database altijd beter is. (of zie ik dat verkeerd?)

Het makkelijker benaderen is dus niet mijn argument, het consequent benaderen wel. Vanuit die optiek is het dus niet fout. Overigens is een database niets meer dan een data opslagplaats. Net zo goed als een filesystem dat ook is. Dat je een (bijvoorbeeld) relationeel model gebruikt om gemakkelijk en snel te kunnen zoeken (etc) in je data doet daar niets aan af. Dit is wel een heel platgeslagen mening en ik kan weet dat hier commentaar op komt, maar als je goed naar de aard van het beestje kijkt is dit zijn hoofdtaak: opslaan en integriteit bewaken. Dat de meeste (relationele) databases ondertussen veel meer kunstjes kunnen doet niets af aan die hoofdtaak.

edit:
hoe komt het toch dat ik het gevoel heb dat we discussieren over iets waar we het over eens zijn?

[ Voor 4% gewijzigd door JaQ op 26-12-2004 20:47 ]

[Skaah]

Ik heb ze zelf in een map staan. Zo kunnen ze eenvoudig geupload worden door mensen met de goede rechten. Met een .htaccess kun je ze dan beschermen. Bovendien moet ik er niet aan denken om nog meer queries op mijn zwaarbelaste databaseserver te sturen. Het filesystem is prima te cachen voor dit soort bestanden. Bovendien hoef ik ze maar weinig in te lezen, aangezien ik gecompileerde templates maak.

Ik maak gebruik van Smarty.

Templates zijn geen relationele data, en horen dus niet in de database thuis. (IMHO)

[Hans1990]

DrFrankenstoner schreef op zondag 26 december 2004 @ 19:57:

ok: ik wil een pagina tonen:

1. open file handle
2. haal bestand (template) op
3. open database handle
4. haal data op
5. merge

(en uiteraard handles sluiten, maar die laat ik wel even achterwege in deze)

in het geval van database:
1. open database handle
2. haal data op
3. haal template op (= eigenlijk hetzelfde als stap 2)
4. merge

Hmmmm, je neemt toch niet serieus met die volgorde van database he ? Er komt nog veel meer bij kijken dan alleen 'haal data op'. Je kan dat wel opsplitsen als Query parsen, Datafile openen en parsen, Data opzoeken, ect. ect. ect.

Met files heb je het voordeel, je weet waar de data staat. MySQL moet die nog opzoeken, en daarvoor gaat ook nog het parsen van de query en de datafile uitlezen/parsen.

Anders kan je wel een testje gaan doen met een simpele database en file aangedreven mini-pagina. Kijken welke het snelst 100 unieke templates van 1KB ophaalt bijvoorbeeld. Ik denk dat files het van de database gaat winnen

[Bosmonster]

Grappige discussie.. de reden voor mij om templates NOOIT in de DB op te slaan: Het is niet te onderhouden. Tenzij je voortaan je PHP in een textarea wil schrijven of extern maken en stuk voor stuk knippen/plakken ofzo

We werken hier met meer dan alleen developers en zoiets kan ik dus niet maken (al zou ik het willen). In een omgeving waar meer mensen werken dan alleen jji als developer is zoiets altijd ongewenst lijkt me.

Het zou handig kunnen zijn als extra om files online (via het cms) aan te kunnen passen, maar dan nog steeds de bestanden zelf en slechts als extra, niet als basis. Persoonlijk zie ik ook hier niet zoveel heil in, een klant heeft bij ons nooit toegang tot de templates namelijk, slechts tot de content en de modules die we leveren.

Performance lijkt me geen issue overigens.. als er al een verschil is is het verwaarloosbaar (en waarschijnlijk in het voordeel van files, gewoon minder overhead van het opzoeken).

[ Voor 41% gewijzigd door Bosmonster op 27-12-2004 00:07 ]

[alienfruit]

Je zou natuurlijk gebruik kunnen maken van WebDAV voor het bewerken van je templates e.d. Dat gebruik ik ook voor mijn huidige CMS en werkt best leuk, vooral in combinatie met bijv. PhotoShop of DreamWeaver en dat zijn nou ook tools die de grafici gebruiken

[BierPul]

Ikzelf heb er wel voor gekozen om de templates in de database op te slaan.

Hiervoor had ik 2 redenen.

• De klanten konden zelf kleine aanpassingen doen, sommige klanten hebben dit als wens en geeft een stukje extra ruimte voor advies (=kassa)

• Ik pas in de template beheer omgeving gelijk versiebeheer toe, waarin ik de laatste 2 versies bewaar, (heeft me al vaak kopzorgen gescheeld )

Dit waren voor mij dan ook de enige 2 opties en dus voordelen

Op zich had ik natuurlijk ook kunnen kiezen om de templates via het filesysteem aan te spreken en de oude file te archiven, de grootte van de templates in dit project waren dusdanig klein dat dit geen winst ging geven.

Bij grotere projecten kan ik me voorstellen dat dit handiger is

[ Voor 26% gewijzigd door BierPul op 27-12-2004 16:22 ]

[Spixo]

BierPul schreef op maandag 27 december 2004 @ 16:18:
Ikzelf heb er wel voor gekozen om de templates in de database op te slaan.

Hiervoor had ik 2 redenen.

• De klanten konden zelf kleine aanpassingen doen, sommige klanten hebben dit als wens en geeft een stukje extra ruimte voor advies (=kassa)

• Ik pas in de template beheer omgeving gelijk versiebeheer toe, waarin ik de laatste 2 versies bewaar, (heeft me al vaak kopzorgen gescheeld )

Dit waren voor mij dan ook de enige 2 opties en dus voordelen

Dat met die versie-beheer klinkt als een zeer interessant argument op database templates toe te passen

[Erkens]

Ricardo87 schreef op maandag 27 december 2004 @ 16:23:
[...]

Dat met die versie-beheer klinkt als een zeer interessant argument op database templates toe te passen

waarom zou dat met files niet kunnen dan
Juist met files is versie beheer erg makkelijk, je zou zelfs een cvs erachter kunnen zetten als je dat wilt.

[Spixo]

Erkens schreef op maandag 27 december 2004 @ 16:26:
[...]

waarom zou dat met files niet kunnen dan
Juist met files is versie beheer erg makkelijk, je zou zelfs een cvs erachter kunnen zetten als je dat wilt.

Ik vind CVS wat te ver gaan voor een "simpele" website. Imho is dit met MySQL makkelijker te realiseren.

[Erkens]

Ricardo87 schreef op maandag 27 december 2004 @ 16:39:
[...]

Ik vind CVS wat te ver gaan voor een "simpele" website. Imho is dit met MySQL makkelijker te realiseren.

natuurlijk gaat cvs nu misschien wat te ver, maar dat is met files makkelijker te realiseren dan met een database, ook het laten ontwikkelen van de templates door meerdere personen is met losse files makkelijker te realiseren dan een database.
Ook backups maken en terugzetten is eenvoudiger dan een database, gewoon de juiste file terug zetten, probeer dat met je database dump maar

Als je dus wilt gaan werken met templates via een database dat je geen standaard tools meer kan gebruiken voor het beheren van de templates..

[JaQ]

Hans1990 schreef op zondag 26 december 2004 @ 23:37:
[...]


Hmmmm, je neemt toch niet serieus met die volgorde van database he ? Er komt nog veel meer bij kijken dan alleen 'haal data op'. Je kan dat wel opsplitsen als Query parsen, Datafile openen en parsen, Data opzoeken, ect. ect. ect.

Met files heb je het voordeel, je weet waar de data staat. MySQL moet die nog opzoeken, en daarvoor gaat ook nog het parsen van de query en de datafile uitlezen/parsen.

Anders kan je wel een testje gaan doen met een simpele database en file aangedreven mini-pagina. Kijken welke het snelst 100 unieke templates van 1KB ophaalt bijvoorbeeld. Ik denk dat files het van de database gaat winnen

Je hebt ook wel gelijk dat ik een paar stappen over sla, maar die sla jij ook over: zoek in je config file welke template je nu nodig hebt, zoek dat op op het filessystem (je hebt wel een directe pointer, maar het is niet zo dat je die "zomaar" opeens in memory hebt) etc.

Ik denk echt niet dat het qua performance echt zoveel uitmaakt. Niet wereldschokkend in ieder geval. Als je vind dat je database overbelast is, moet je misschien eens een tweede database opzetten ipv alles in een bak willen gooien. (om dat argument ook meteen maar te bestrijden).

Erkens schreef op maandag 27 december 2004 @ 16:43:
[...]

natuurlijk gaat cvs nu misschien wat te ver, maar dat is met files makkelijker te realiseren dan met een database, ook het laten ontwikkelen van de templates door meerdere personen is met losse files makkelijker te realiseren dan een database.
Ook backups maken en terugzetten is eenvoudiger dan een database, gewoon de juiste file terug zetten, probeer dat met je database dump maar

Als je dus wilt gaan werken met templates via een database dat je geen standaard tools meer kan gebruiken voor het beheren van de templates..

hij noemt toch mysql, dan is een backup toch gewoon het terug zetten van een file (dump is iets moeilijker, maar goed.. andere discussie en bovendien een foute flame richting mysql, wat in mijn optiek toch een flat file system is waar je toevallig sql tegen kan roepen).

Ik denk wel dat cvs makkelijker op te zetten is dan versiebeheer in een database. Vooral omdat de gemiddelde web ontwikkelaar een betere kennis heeft van cvs dan van het ontwerp van versiebeheer (IMHO). Op zich niet zo belangrijk, beide opties zijn mogelijk.

Het argument dat bosmonster noemt (editor moet textarea of externe editor zijn) is wel heel waar. Dit is een groot nadeel van het opslaan in een database. Beheersbaarheid is in mijn optiek geen probleem. Dat ligt er namelijk aan bij wie de verantwoording hiervoor ligt. Als er meerdere mensen aan 1 template werken hoeft dat geen probleem te zijn, als je een fatsoendelijke locking mechanisme hebt. Dat werkt op een filesystem gelijk aan een database m.i.

Skaah schreef op zondag 26 december 2004 @ 21:06:
Templates zijn geen relationele data, en horen dus niet in de database thuis. (IMHO)

goh... dus je template is niet gerelateerd aan 1 site, of 1 klant, of een menuoptie (etc)? Als je 1 systeem gebruikt voor 100 websites, dan is een template absoluut relationele data.

Anyway, ik blijf er bij dat het aan voorkeur/willekeur van de ontwikkelaar ligt. Ik heb tot op heden nog steeds geen sterke argumenten gehoord waarom een van beide methodes beter is.

[Bosmonster]

Ik heb ook nog geen bruikbare voordelen gehoord van het in de DB op te slaan. Ik kan alleen maar nadelen bedenken (en een daarvan is zo groot dat ik dit nooit en te nimmer in een database zal gooien).

De ontwerpers en html'ers hier zien me al aankomen

Als je templates in de DB opslaan handig vindt, dan zul je ook wel afbeeldingen op gaan slaan in de DB? En JS files? En CSS files? Ik kan de logica ff niet vinden

Wat ik hierboven zie zijn 'voordelen' als:

- minder files in je FTP (lol)
- sneller (bs)
- versiebeheer (kan ook met files als je het al zou willen)
- editen via CMS (kan ook met files en dan sluit je het andere tenminste niet uit, namelijk gewoon fatsoenlijk kunnen werken in een willekeurige editor en uploaden)

Als dat alles is

Klanten toegang geven tot HTML is overigens het laatste dat we hier zouden doen. 99% weet niet eens wat het is en die 1% die wel weet wat het is kan er beter met zn tengels vanaf blijven En het is meer 'kassa' om wijzigingen gewoon te laten offreren hoor

Maar goed.. ieder bedrijf z'n meuk....

[ Voor 74% gewijzigd door Bosmonster op 27-12-2004 18:26 ]

[Erkens]

DrFrankenstoner schreef op maandag 27 december 2004 @ 17:28:
hij noemt toch mysql, dan is een backup toch gewoon het terug zetten van een file (dump is iets moeilijker, maar goed.. andere discussie en bovendien een foute flame richting mysql, wat in mijn optiek toch een flat file system is waar je toevallig sql tegen kan roepen).

mysql en een backup alleen een file terug zetten?
Zeker nog nooit serieus met mysql gewerkt dus
Daarnaast is elke DB in principe gewoon een zooi files waar je sql tegen kan roepen.