[PHP] user-instellingen uit files of uit een database *

[OkkE]

Hallo allemaal,

_{edit -- argh topic verkeerd, moet user-instellingen zijn ipv website instellingen -- /edit}

Op dit moment ben ik bezig met het maken van een website. Een aantal mogelijkheden van de site zullen zijn:
• Inloggen / profiel aanmaken
• Reageren op nieuws en artikelen
• Stemmen op een poll
• Gastenboek / forum
• Kiezen van een layout (vast aantal)

Nu wil ik de users de mogelijkheid geven om dingen als de layout zelf aan te passen, een aantal opties zouden kunnen zijn:
• Hoeveel nieuwsberichten wil de gebruiker zien?
• Welke kleur wil de user de achtergrond?
• Wel of niet de laatste berichten van het forum laten zien op de home?
• Nieuws bovenaan of de poll, of het stats-scherm?

Dit kan op 3 manieren:
A. Dmv een Cookie,
B. Alles in een database bijhouden,
C. Bestanden ($userid.dat) op de server.

Cookies wil ik niet, aangezien dit per comp is en niet per user. Ik wil dat de user, welke comp hij ook gebruikt, altijd de instellingen heeft na het inloggen.

Dan een database of losse bestanden?

Het idee met de bestanden was zo, in een bestand staat bijv. $theme = 'rood.css'; welke geinclude wordt door: include ($userid . '.dat');

Na een benchmark kwam ik er namelijk achter dat files de helft aan tijd kost. 1000x een bestand includen met vars is 0,7 sec en het 1000x ophalen van vars uit een database (connectie maken, ophalen, connectie sluiten, opnieuw) koste 1,4 sec.

Het aanpassen van de instellingen is aan de andere kant via een database iets fijner, vind ik persoonlijk.

Mijn vraag
Klopt mijn benchmark, of is mijn testserver gewoon brak?
En op welke manier doen jullie het bovenstaande; instellingen van users onthouden?

[ Voor 4% gewijzigd door OkkE op 07-07-2004 10:49 ]

[Cavorka]

Het hangt een beetje af van hoeveel instellingen je hebt (en dus hoe groot je te includen bestand wordt). Er is zeker een moment waar het includen meer tijd gaat kosten dan het ophalen uit de database. Je benchmark zal zeker wel kloppen, maar hoe groot zijn je user-instellingen-files nu?

Wat je zelf al zegt: je kan wel met files werken (ikzelf heb het ook een hele tijd gedaan, zelfs een heel forum ermee gemaakt), maar dingen als zoeken in userinstellingen is nogal een *** werk met al die files en wordt echt rete-traag. Wat je zelf ook al zegt: de een kost ongeveer 0.0007 seconde en de ander 0.0014. Het mag dan wel 2x zo langzaam zijn, maar who cares? Alsof je dat ooit gaat merken.

Als je een beetje ervaring hebt met databases (of eigenlijk ook als je dat niet hebt), zou ik zeggen: ga voor de database. Uiteindelijk zal het sneller zijn, veeeeeel makkelijker schaalbaar, een uiteraard veel 1337'er.

PS: Benchmark van mij, van een jaar geleden:

code:

3. - Inclusion of a 40kb file vs a 2kb file.
1-9-2003 17:51 - Results:
500 cycles:
    40kb file:  26.94s, 1 cycle: 0.05389s
    2kb file:   0.5s, 1 cycle: 0.001s

So I would say the difference is rather shocking.

500 cycles, with unsetting all variables each cycle:
    40kb file:  9.77s, 1 cycle: 0.01953s
    2kb file:   0.49s, 1 cycle: 0.001s

A little less shocking, but still quite amazing.

---------------------------------------

@Simon: indeed, jammer alleen dat je dan je eigen write_ini_file functie moet schrijven, maar dat is wel te doen.

[ Voor 34% gewijzigd door Cavorka op 07-07-2004 11:05 ]

[simon]

Je kan ook met .ini files werken (zie parse_ini_file functie @ php.net)

[Johnny]

Het lijkt mij dat je de gebuikersnaam en wachtwoord enz. ook in een database opslaat, je zult dus sowieso een SELECT query moeten doen, als je daar nog een paar andere waarden uithaalt kost dat veel minder tijd dan in bestanden gaan zitten lezen/schrijven.

[creative8500]

Een combinatie van die drie is ook niet ongebruikelijk:

1. Bezoeker logt in op je site, waarop je aan de query waarmee je het wachtwoord controleert een JOIN toevoegt, waarmee je de user-preferences ophaalt. (B - een database)
2. Bezoeker komt op bijvoorbeeld de homepagina, en verstuurt een cookie met zijn SESSID mee. (A - d.m.v. een cookie)
3. Jij haalt de instellingen uit een bestand door de session te openen. (C - de bestanden op server)

[gorgi_19]

Waarbij je met een beetje geluk de userpreferences ook als integerveld kan opslaan (dmv het gebruik van bitfields), zodat je niet eens een join nodig hebt.

[OkkE]

Het zal gaan om iets van max 10 instellingen denk ik. Maar inderdaad, ik moet toch een query uitvoeren voor het ophalen van andere data, dan kan er net zo goed een user-settings tabel bij.

@creative8500: Ik was ook wel van plan met Cookies te werken, maar niet om daar alle instellingen in op te slaan.

@gorgi_19: Het zullen helaas ook een aantal string-waardes zijn.

Conclusie tot nu
Ik ga voor een database. Ik ga er nu vanuit dat er niet meer instellingen bij komen, maar je weet het natuurlijk nooit. In zo'n geval is een database makkelijker. En er is natuurlijk al een connectie voor de overige info, kost het ophalen van wat extra user-settings ook nix.

Alvast bedankt voor alle reacties. Ik sta altijd open voor andere ideeen.

_{nu eten..}

[djluc]

Je zorgt wel voor een goede database opzet zodat een optie toevoegen niet erg ingewikkeld wordt?

[creative8500]

djluc: Je zorgt wel voor een goede database opzet zodat een optie toevoegen niet erg ingewikkeld wordt?

"Echt niet! Waar zie je mij voor aan?!" * creative8500 is *

[vargo]

Ik zou zelf voor een database gaan.

Maar om even wat te brainstormen, je zou natuurlijk ook (wellicht later) aan bijv XML kunnen denken. Even wat puntjes:
- ik gebruik sowieso altijd een database abstraction layer. Mijn favoriet is ezSQL (http://php.justinvincent.com), maar ook de PEAR database abstraction layer (http://pear.php.net/package/DB) of adoDB (http://adodb.sourceforge.net/) zien er goed uit.
- met PHP5 voor de deur (eind deze week willen ze de final release uitbrengen heb ik gehoord) zal XML een stuk makkelijker te benaderen worden met SimpleXML (http://www.php.net/manual/en/ref.simplexml.php).
- Met tools als XML Serializer (PEAR: http://pear.php.net/package/XML_Serializer) is het erg makkelijk om te vertalen tussen php data structuren (arrays, objecten) en XML. Daarmee kan je dus makkelijk vertalen tussen je database en XML. Dit is makkelijk als je besluit te switchen van 1 techniek naar de ander, maar je kan ook denken aan het 'cachen' van je usersettings naar xml, of het aanbieden van de instellen in XML aan andere systemen of de eindgebruiker zelf.
M.a.w. door nu goed over je structuur na te denken zou je later flexibel genoeg moeten zijn om over te stappen.

Een beetje offtopic, maar wellicht leuk om te vermelden: ik gebruik deze tools om de flexibiliteit van een database te combineren met het scheiden van 'content' en 'looks'.
- ik haal de resultaten van mijn queries uit de database in de vorm van arrays en objecten (mbv ezSQL)
- ik vertaal deze resultaten naar XML bestanden (incl DTDs). Nu heb ik daar zelf een class voor geschreven, maar ik wil dit later bij voorkeur door XMLSerializer laten doen.
- met de Sablotron XSLT extensie vertaal ik de XML bestanden naar XHTML bestanden.
- door gebruik te maken van 'standaard' data structuren in de database, krijg ik ook 'standaard' data structuren in XML. Bij het transformen van data->XML wordt er vanuit een XSLT library ook een XSLT bestand gegenereerd welke naderhand helemaal aan te passen is.

[OkkE]

djluc schreef op 07 juli 2004 @ 12:32:
Je zorgt wel voor een goede database opzet zodat een optie toevoegen niet erg ingewikkeld wordt?

Natuurlijk. Maar ik was eerst nog eens aan het nadenken hoe ik het ging doen; database of niet.

vargo schreef op 07 juli 2004 @ 12:58:
[...]

Dat 'cachen' van XML files is dus wat ik bedoel met mijn *.dat files. Oke, ik noemde het dat, maar kan ook XML. Ik zie alleen - met dit onderwerp (instellingen) - niet dierect de toeveogende waarde van XML. Aangezien het altijd op een PHP server zal blijven draaien, en alleen web-based zal zijn; waardoor benadering door andere 'dingen' zeer onwaarschijnlijk is.

En het scheiden van content en data dmv DB > XML > XSLT > XHTML, vind ik persoonlijk, voor dit projectje iig, niet nodig.

[curry684]

OkkE schreef op 07 juli 2004 @ 10:48:
_{edit -- argh topic verkeerd, moet user-instellingen zijn ipv website instellingen -- /edit}

Zet dat voortaan aub in een TR, dan zien we het tenminste Fix0red iig.

Na een benchmark kwam ik er namelijk achter dat files de helft aan tijd kost. 1000x een bestand includen met vars is 0,7 sec en het 1000x ophalen van vars uit een database (connectie maken, ophalen, connectie sluiten, opnieuw) koste 1,4 sec.

Goh, meen je nu serieus dat het direct benaderen van een file sneller is dan via een IPC interface een SQL query doorsturen die gecompileert moet worden en vervolgens dezelfde data uit een file trekken? Beetje 'stating the bloody obvious' he

Een database met platte data gebruik je niet voor de snelheid maar voor de flexibiliteit. De stunt komt zodra je gaat joinen of op indexes filteren, dan blijven je flatfiles ineens meters achter bij de RDBMS.

Lees ook voor de lol dit geniale <!-- lees: dieptrieste -->topic eens door over performance persen uit DB's tegenover flatfiles: [rml][ MYSQL] 150 kolommen of 2 kolommen?[/rml]

[OkkE]

@curry684:
Ja, ik geef toe dat het een beetje 'stating the bloody obvious' was. Maar het ging me ook vooral om wat anderen hier over te zeggen hadden; files of database dus.

En dat files minder flexibel zijn, dat is logisch.. Maar het includen van een file geeft wel iets minder load als het opvragen van info uit een database, lijkt me. Ik ben in iedergeval al wel tot de conclusie gekomen dat ik een database ga opzetten.

En dat 'geniale' topic heb ik ook gevolgd inderdaad. Ik heb er in het begin zelfs nog wel een beetje om kunnen lachen ook.

[vargo]

OkkE schreef op 07 juli 2004 @ 13:27:Dat 'cachen' van XML files is dus wat ik bedoel met mijn *.dat files. Oke, ik noemde het dat, maar kan ook XML. Ik zie alleen - met dit onderwerp (instellingen) - niet dierect de toeveogende waarde van XML. Aangezien het altijd op een PHP server zal blijven draaien, en alleen web-based zal zijn; waardoor benadering door andere 'dingen' zeer onwaarschijnlijk is.

En het scheiden van content en data dmv DB > XML > XSLT > XHTML, vind ik persoonlijk, voor dit projectje iig, niet nodig.

Het zal hier ongetwijfeld overkill zijn om zo'n aanpak te hanteren. Mijn toevoeging was meer algemeen bedoeld. Ik ben voor mezelf zover dat ik systeem ontwikkeling anders wil benaderen. Dus niet het wiel iedere keer opnieuw uitvinden, niet code iedere keer opnieuw moeten kloppen, en wel altijd een uniforme gestructureerde methodiek toepassen. Bovenstaand maakt dus deel uit van een (spoedig open-source) project, waarbij de nadruk ligt op het efficient ontwikkelen van webbased systemen welke wel 100% aan te passen moeten zijn. De nadruk ligt hierbij op het vastleggen van het probleemdomein (wellicht UML), een flexibele, modulaire opzet van het systeem, scheiding van data en opmaak etc.

/Edit: om even terug te komen op 'file of database?': mijn inziens zal het antwoord meestal op database uitkomen puur vanwege de flexibiliteit. De enige situaties waarbij ik voor file zou kiezen zijn:
- indien er geen dbase mogelijkheden zijn
- als het z grote data objecten betreft. Ik zou dan echter de meta-data alsnog in een database opslaan en laten verwijzen naar het fysieke bestand.
- wanneer performance echt een issue gaat worden. Alhoewel ik me afvraag of een heel grote file doorzoeken danwel zeer veel kleine files wel een noemenswaardig prestatievoordeel geeft. Alleen boomstructuren zullen hierbij een echt voordeel kunnen gaan vormen.

[ Voor 26% gewijzigd door vargo op 07-07-2004 13:54 ]

[OkkE]

vargo schreef op 07 juli 2004 @ 13:48:
[...]

/Edit: om even terug te komen op 'file of database?': mijn inziens zal het antwoord meestal op database uitkomen puur vanwege de flexibiliteit. De enige situaties waarbij ik voor file zou kiezen zijn:
- indien er geen dbase mogelijkheden zijn
- als het z grote data objecten betreft. Ik zou dan echter de meta-data alsnog in een database opslaan en laten verwijzen naar het fysieke bestand.
- wanneer performance echt een issue gaat worden. Alhoewel ik me afvraag of een heel grote file doorzoeken danwel zeer veel kleine files wel een noemenswaardig prestatievoordeel geeft. Alleen boomstructuren zullen hierbij een echt voordeel kunnen gaan vormen.

Database is mogelijk.

Maar ik kwam op het idee van files aangezien het - voorlopig - om een x-aantal vaste variabelen gaat. Ik kwam toen op het idee om een include-file te maken waar deze waardes in zouden staan, zodat ik niet steeds een query hoefde te doen. Maar het aanpassen van die instellingen (in een file) werkt natuurlijk minder fijn, plus dat files niet echt flexiebel zijn.

En toen ging ik mij afvragen hoe anderen het doen. Ik maak namelijk wel altijd 1 file met de instellingen als titel van de website, db-gegevens, enz enz. ipv dat in een database te zetten.

[vargo]

OkkE schreef op 07 juli 2004 @ 13:59:
[...]
En toen ging ik mij afvragen hoe anderen het doen. Ik maak namelijk wel altijd 1 file met de instellingen als titel van de website, db-gegevens, enz enz. ipv dat in een database te zetten.

Ja idd: dat gaat meestal in een config.incl.php en iets als header.incl.php / footer.incl.php.

En er zijn soms toch ook nog wel de 'smerig gecodeerde', snelle scriptjes alhoewel ik dat zoveel mogelijk probeer te vermijden

[ Voor 16% gewijzigd door vargo op 07-07-2004 14:03 ]