"ontwerp" keuze, status website
Ten tweede, je hebt het over een CMS. Dus ik denk dan (maar verbeter me waar ik teveel aannames maak) dat de gegevens van de site in de database staan. Dat daarbij de content van de pagina die wordt opgeroepen in de database staat. Dus dat als iemand een pagina oproept, je altijd al die database in zult moeten om die content op te vragen. Wat is er dan makkelijker om bij de gegevens van de site en pagina die je dan al oproept, ook nog het 'status' veld erbij te selecteren?
Ten derde, wat denk je dat het kost om een (in dit geval extra!) bestand te openen als je het in een config bestandje gooit. Dacht je echt dat dat geen tijd kost?
Ik heb je eerder al regel 1 uitgelegd, dan nu regel 2. Ga data niet van elkaar scheiden waar het absoluut duidelijk is dat het bij elkaar hoort. Als jij al je website data in de database zet, maar alleen dat status veld niet, hoe denk je dan dat je die ook nog mooi bij elkaar kunt krijgen. Stel je wilt voor je admin paneel een overzicht hebben van alle websites die niet actief zijn..... hoe ga je die selecteren via die config bestandjes? Veel succes....
Gewijzigd op 27/01/2013 13:54:27 door Erwin H
Waar ik tussen twijfel... stel ik haal de status op uit de database. Doe je dit dan bij iedere pagina aanroep, of doe je dit 1x per sessie? Als ik het 1x per sessie doe, houdt dat in dat voor iedere bezoeker van een van de websites op de vps een sessie-bestand moet worden aangemaakt, zels als die sessie verder nergens anders voor wordt gebruikt. Vandaar dus dat ik dacht aan een config bestand.
Maar wat dan misschien handiger is, is toch het gebruik van database cache bestanden. Dan lees ik gewoon bij iedere pagina-aanroep dat cache bestandje in en dan hoef ik dus geen sessie te maken. Wat vind jij daarvan?
Cachen is een mogelijkheid die je zou kunnen gebruiken. In essentie sla je nog steeds data dubbel op, maar in het geval van een cache is dat juist de bedoeling en accepteer je het feit dat de cache op zeker moment mogelijk verouderd is. Dat is een trade off tegen de betere performance (indien je het goed opzet uiteraard). Maar persoonlijk zou ik eerst eens gaan testen of het wel zo nodig is. Is het uitlezen van die status wel zodanig belastend dat je er een oplossing voor moet hebben? Jij denk dat wel, maar ik vraag me af of je dat ook al getest hebt.
Ik heb het nog niet getest inderdaad... maar het feit dat je iedere keer hetzelfde gegeven uit de database ophaalt... tja, dan vraag ik me af of dat nodig is, snap je? Dus vandaar eigenlijk. Je zegt dat een sessie in jouw ogen niet voor dit soort gegevens is bedoeld. Waar is een sessie volgens jou wel voor bedoeld? Voor welke gegevens?
In jouw geval heeft die status echter niets te maken met de gebruiker of sessie, waardoor het wat mij betreft dus niet in de sessie gegevens terecht zou moeten komen.
En ja, ik snap je idee wel dat je niet elke keer in die database wilt kijken. Echter, wat ik denk dat jij vergeet is dat welke oplossing je ook kiest, je altijd in 'een database' moet kijken. In feite is een bestand namelijk ook een record in de grote database van je server waar alle bestanden in opgeslagen zijn. Over het algemeen nog een vrij trage database ook.... Dus wat los je nu werkelijk op door het van de ene database naar de andere te copieren?
Wat betreft het database verhaal... ik heb altijd gehoord dat je database aanroepen zoveel mogelijk moet vermijden en dat iets ophalen uit een bestandje sneller gaat dan een database connectie maken en iets ophalen uit de database. Vandaar mijn overdenkingen.
Als algemene regel stellen dat je database aanroepen moet vermijden zou ik niet direct willen zeggen. Het kost wel tijd inderdaad en als je dus op zeker moment in de problemen komt zou minder database aanroepen kunnen helpen. Alleen, soms kan de kuur ook erger zijn dan de kwaal. Koste wat kost database aanroepen vermijden, maar dan terecht komen in oplossingen die nog erger zijn helpt dus ook niet. Vandaar mijn opmerking over het testen. Test of je oplossing beter is dan elke keer de database aanroepen. Zo ja (en is die database aanroep ook daadwerkelijk een struikelblok) dan valt het te overwegen om iets anders te doen.
Oké, ik begrijp wat je bedoelt. Thanks.