[CMS] instellingen opslaan

[Foutlook]

Ik wil een eigen CMS gaan bouwen als schoolopdracht (nee, ik ga hem niet in de markt zetten en ja, ik weet dat er al ontelbaar zijn). Het is voor mij meer een manier van ervaring opdoen door zo'n systeem te bouwen.

Nu zit ik met het vraagstuk hoe om te gaan met gebruikersinstellingen. Dit zijn een aantal velden zoals naam, adres, telefoon etc, maar ook layout voorkeuren etc.

optie 1
Ik schrijf alles weg in een tekstbestand in de vorm van:
$instelling_1 = value;
$instelling_2 = value;
etc (zoals die language files die je altijd ziet)

Voordeel: weinig laadtijd, geen db connectie nodig.
Nadeel: lijkt me lastig om een instelling te wijzigen in een tekstbestand.

optie 2
Ik schrijf alles weg in een database (tabel instellingen, velden 'naam' en 'waarde')
Voordeel: makkelijk aanpasbaar met simpele INSERT of UPDATE
Nadeel: elke keer moet er een connectie gemaakt worden met de database.

Wat is volgens jullie het handigste om te doen?

[Dennis]

Optie 2 is het meest gemakkelijk. Een andere manier is om met xml bestanden te werken, daarin kun je ook makkelijk settings opslaan en ze zijn (als je éénmaal de functies hebt gemaakt) gemakkelijk te wijzigen.

[We Are Borg]

Nadeel optie 1 en wat dus voordeel is van optie 2: optie 1 is niet gebruikersvriendelijk

[Erkens]

als uitbreiding op optie 1 zou je ook voor XML kunnen kiezen, daar heb je voor PHP kant en klare functions
Of je saved de info op door alles in een array te zetten en dan met serialize() in een op te slaan formaat te zetten...

optie 2 is ook wel wat voor te zeggen als je verder nog gebruik maakt van die Database, want waar save je de content?

[elnino]

Het is belangrijk om te kijken welke opties vaak veranderd worden. Sommige instellingen zullen hooguit één keer veranderd worden (denk aan lay-outinstellingen), terwijl andere instellingen vaker veranderd zullen worden. Als het om opties die in principe niet veranderd worden, zou ik het gewoon in een include-bestand zetten en anders kun je inderdaad een MySQL-database o.i.d. gebruiken als opslag.

[Foutlook]

Erkens schreef op maandag 31 januari 2005 @ 13:15:
als uitbreiding op optie 1 zou je ook voor XML kunnen kiezen, daar heb je voor PHP kant en klare functions
Of je saved de info op door alles in een array te zetten en dan met serialize() in een op te slaan formaat te zetten...

optie 2 is ook wel wat voor te zeggen als je verder nog gebruik maakt van die Database, want waar save je de content?

De content wordt in dezelfde MySQL database opgeslagen, er zou dus gewoon een tabelletje bijkomen. Ok, bedankt voor de reacties, het lijkt me dat optie 2 het gaat worden, al ga ik nog even kijken naar het XML gebeuren. (Ikzelf heb wel eens een php script gemaakt wat een RSS-feed als output geeft, maar zie zo nog niet in hoe ik dit kan gebruiken als instellingenbestandje.)

[jeanj]

Bouw een leuke (web)interface waarmee je de configuratie kan wijzigen en dan is de manier van opslag onafhankelijk van de gebruiksvriendelijkheid van de gebruiker.

Als je nu een mooije api/interface schrijft voor de opslag en opvragen van je settings, dan kun je het altijd gemakkelijk herschrijven.

Mijn keuze, tekst file snel en simpel, dbbase mooi en lekker schaalbaar. De laatste heeft mijn voorkeur, tenzij tijd een issue is.

[Verwijderd]

Met het inlezen van en wegschrijven naar bestanden is de server misschien nog wel langer bezig dan met het query-en van een database (die toch al als proces draait). Althans, in asp wel. Ik zou zeker kiezen voor een database, omdat een database veel makkelijker uitbreidbaar is. Bovendien is een database voor een eventueel volgend project makkelijker herbruikbaar dan losse tekstbestanden

[Anders]

Foutlook schreef op maandag 31 januari 2005 @ 13:11:
optie 2
Ik schrijf alles weg in een database (tabel instellingen, velden 'naam' en 'waarde')
Voordeel: makkelijk aanpasbaar met simpele INSERT of UPDATE
Nadeel: elke keer moet er een connectie gemaakt worden met de database.

Is dat een nadeel? Hoeveel mensen gaan van het CMS gebruik maken? 100.000?

Even reëel: een doorsnee CMS zal op z'n hoogst door een paar personen tegelijkertijd gebruikt worden, en misschien per persoon een kwartier per dag. Het is volstrekt van de zotte om het bij dat soort aantallen te hebben over performance-issues van een extra query per pagina. Optimaal programmeren is prima, maar zeker voor een CMS moet je niet gaan beknibbelen op functionaliteit ten gunste van dit soort onmeetbaar kleine performance-factoren.

[Dennis]

In wat voor taal ga je het eigenlijk maken ?

[Foutlook]

Anders schreef op maandag 31 januari 2005 @ 14:54:
[...]


Is dat een nadeel? Hoeveel mensen gaan van het CMS gebruik maken? 100.000?

Even reëel: een doorsnee CMS zal op z'n hoogst door een paar personen tegelijkertijd gebruikt worden, en misschien per persoon een kwartier per dag. Het is volstrekt van de zotte om het bij dat soort aantallen te hebben over performance-issues van een extra query per pagina. Optimaal programmeren is prima, maar zeker voor een CMS moet je niet gaan beknibbelen op functionaliteit ten gunste van dit soort onmeetbaar kleine performance-factoren.

Nee, geen 100.000. Maar wel meer dan de paar personen die jij suggereert. De bedoeling is dat het beheersysteem centraal komt te staan, zodat er in principe ontelbare websites op aangesloten kunnen worden. Door inlognaam en wachtwoord weet je welke database er moet worden gebruikt, en krijgt de gebruiker zijn eigen content te zien.

Daarnaast beknibbel ik in dit geval helemaal geen functionaliteit. Ik vroeg alleen hoe ik deze functionaliteit (het opslaan van gebruikersvoorkeuren) het beste kan inbouwen, niet of ik die wel of niet moet inbouwen.

Daarnaast denk ik inderdaad ook niet dat beide opties performance-problemen zullen veroorzaken. Ik vind het alleen fijn om de mooiste/snelste manier te kiezen

En in reactie op een andere vraag: ik ga het bouwen in php, gecombineerd met een MySQL database.

[PrisonerOfPain]

We Are Borg schreef op maandag 31 januari 2005 @ 13:15:
Nadeel optie 1 en wat dus voordeel is van optie 2: optie 1 is niet gebruikersvriendelijk

Als je een geserializede array in een bestand stopt, heb je dat probleem weer niet met optie 1. Omdat je daar dan ook een netter UI voor kunt schrijven die de instellingen opslaat.
Punt is dan, dat je nogal een verspreiding van je gegevens krijgt.

[Verwijderd]

Ik zou het persoonlijk in de database opslaan, zodat de wijzigingen in gegevens worden meegenomen in de database bij backups. Ligt er natuurlijk ook helemaal aan hoevaak je backups van je filesystem maakt.

Qua performance, als je echt veel traffic verwacht zet je de variabelen toch gewoon in een session, of cookies

[djluc]

Mee eens. Ook zie je vaak dat configuratiebestanden weer incompitabel zijn bij nieuwere versies e.d. Dat kan je allemaal voorkomen.

[Erkens]

Verwijderd schreef op maandag 31 januari 2005 @ 19:45:
Ik zou het persoonlijk in de database opslaan, zodat de wijzigingen in gegevens worden meegenomen in de database bij backups. Ligt er natuurlijk ook helemaal aan hoevaak je backups van je filesystem maakt.

als je backups serieus neemt, dan neem je ook je configuratie files etc mee Dus: onzin argument.

Qua performance, als je echt veel traffic verwacht zet je de variabelen toch gewoon in een session, of cookies

Als je dat doet maakt het toch ook niet uit of het in een DB staat of een losse file

djluc schreef op maandag 31 januari 2005 @ 20:10:
Mee eens. Ook zie je vaak dat configuratiebestanden weer incompitabel zijn bij nieuwere versies e.d. Dat kan je allemaal voorkomen.

En database tabellen niet zeker

[Verwijderd]

Lijkt me nogal logisch ja dat het niet meer uitmaakt of je je session nu vult vanuit een xml of database bron, waar heb je anders die session nog voor

En ja, het kan in geval van backups zijn dat er in het kader van relaties met andere data icm profieldata je dus een backup van het filesystem niet synchroon hebt lopen met de backup van je database, kortom de integriteit zou zomaar niet meer kunnen kloppen. Een van de redenen waarom er nog steeds mensen zijn die liever files in de database stoppen. Zeker met veel traffic is de kans hierop groot.

Stel je voor, je voegt een afbeelding toe via het CMS, slaat de afbeelding op in een filesystem, en het pad in de database (ja een database is ook een filesystem, maar is voor dit voorbeeld niet relevant). Opeens gaat er iets kapot, en staat er een pad in de database naar een file die op het filesystem niet meer bestaat, immer de database had al wel een backup gekregen en het filesystem nog niet. Het is maar een voorbeeld.

Het hangt daarom totaal van de requirements van de topicstarter af wat de beste oplossing is.

[Michali]

Het snelste is gewoon direct een php bestand inlezen. Als je het uit de database moet lezen, moet je eerst een array aanmaken waarin de variabelen staan. En alles opslaan in een sessie is dan echt niet sneller lijkt me. Mischien heeft het wel voordeel als je het gebruikt in samenwerking met een database, maar dan nog is gewoon direct een bestand includen iets sneller.

[PrisonerOfPain]

Michali schreef op dinsdag 01 februari 2005 @ 10:41:
Het snelste is gewoon direct een php bestand inlezen. Als je het uit de database moet lezen, moet je eerst een array aanmaken waarin de variabelen staan. En alles opslaan in een sessie is dan echt niet sneller lijkt me. Mischien heeft het wel voordeel als je het gebruikt in samenwerking met een database, maar dan nog is gewoon direct een bestand includen iets sneller.

Ik denk dat je, voor een school opdracht, niet met van die enorme performance problemen te maken krijgt dat je uberhaupt met dit soort optimalisaties bezig moet zijn.

[Michali]

PrisonerOfPain schreef op dinsdag 01 februari 2005 @ 10:48:
[...]

Ik denk dat je, voor een school opdracht, niet met van die enorme performance problemen te maken krijgt dat je uberhaupt met dit soort optimalisaties bezig moet zijn.

Het was ook meer een reactie op een aantal bovenstaande reacties. En als het echt een zware performance hit is, dan is het wel goed om er naar te kijken, maar in dit geval gaat dat niet echt op.