Ik heb 500 variabelen, welke ik in de rest van de applicatie nodig heb.

Wat is dan de meest elegante oplossing:

1) stop ik ze in een include-file dat ik in ELKE pagina opnieuw laad (slecht voor performance?) en waardoor het "gewone" variabelen worden?
2) stop ik ze in sessies, zodat ik ze maar 1x hoef te initiëren (slecht voor memory-gebruik?)
Meten is weten, maar effectief zijn sessievariabelen niet sneller dan gewoon gebruik van variabelen. Sessies zijn bruikbaar voor gegevens die je niet kunt herleiden uit de gegevens die je al hebt. Denk daarbij aan login gegevens, flashes etc.
Het gaat me nog niet eens om de snelheid, maar meer om performance-verlies (door het telkens herladen) versus memory-gebruik (door alles in sessies te proppen)....
Dus het gaat je niet om de snelheid, maar om de performance. Leg me het verschil eens uit. Sessies verbruiken inherent meer resources (niet qua geheugen, ze kosten je net zoveel als welke variabele dan ook, maar disk access) en omdat het ook "gewoon" variabelen zijn win je er ook niets mee. Of het uit een include moet komen of uit een session file maakt niets uit. Het moet alsnog geladen worden.
Cees Rijken op 11/06/2016 10:52:53

stop ik ze in een include-file dat ik in ELKE pagina opnieuw laad

Wat voor waarden zijn het? Ik zou namelijk zeggen dat je includes vooral gebruikt voor constanten voor meerdere gebruikers en sessies voor variabelen van één gebruiker.
Wat @Ward zegt - over wat voor data hebben we het, en hoe ga je hiermee om? Is deze data voor eenieder verschillend, of voor eenieder hetzelfde?

Mijn eerste ingeving was eigenlijk: indien je data permanent nodig hebt op elke pagina, sla deze dan op in een database. Data in een sessie heeft een beperkte levensduur. Waarom zou je iets wat je permanent nodig lijkt te hebben opslaan (edit: of liever gezegd elke keer opnieuw overhevelen) in een vluchtig medium?

Maar zonder dat je ons uitlegt wat voor data het betreft en hoe je hier mee omgaat (en of deze mogelijk verschillende verschijningsvormen heeft) blijft dit alles koffiedik kijken.

NB zelfs als dit configuratievariabelen zijn ofzo is er iets voor te zeggen om deze in een database op te slaan omdat je via die weg een interface kunt maken waarmee deze waarden interactief aan te passen zijn zonder een wijziging in je broncode.
Het zijn woorden die vertaald worden, dus voor iedere gebruiker gelijk.

Uit de database halen voor elke pagina en elke gebruiker? Dat lijkt me helemaal niet efficiënt!

Vandaar dat ik wil kiezen tussen laden bij elke pagina EN elke gebruiker (variabelen) of eenmalig laden voor elke gebruiker (sessies)....
>> Het zijn woorden die vertaald worden, dus voor iedere gebruiker gelijk.

Dan zet je die niet in een sessie, maar óf in een bestand óf in een database. Beide hebben voor- en nadelen. Het voordeel van een database is dat je de woorden via een zelfgemaakte tool zou kunnen toevoegen en wijzigen. Het nadeel is dat het opzetten van een databaseconnectie (in theorie) iets langzamer is dan het inlezen van een bestand.

Mijn advies, omdat het gaat om data die niet snel zal veranderen zou ik kiezen om het in een bestand te zetten.

Heb je daadwerkelijk al die 500 vertalingen op iedere pagina nodig? Nee? Maak dan per pagina een bestand met daarin alleen de woorden die je echt nodig hebt op die pagina.

[size=xsmall]Toevoeging op 11/06/2016 17:41:41:[/size]

>> Vandaar dat ik wil kiezen tussen laden bij elke pagina EN elke gebruiker (variabelen) of eenmalig laden voor elke gebruiker (sessies)....

Sessies moet je dus helemaal vergeten.
>> Uit de database halen voor elke pagina en elke gebruiker? Dat lijkt me helemaal niet efficiënt!
Leuk zo'n aanname, maar meer dan dat is het niet. Een aanname. Heb je gemeten hoeveel tijd het kost? Je hebt het over verschillen in de orde van microseconden bij zo'n kleine dataset. Stop je tijd in iets zinnigers dan premature optimalisatie.

Hoe je je vertalingen opslaat is niet heel relevant. Het belangrijkste is dat het geen sessie data betreft, het zijn geen dingen die per gebruiker anders zijn. Stop het in de database, maak er includes van, gebruik gettext, het is allemaal om het even.

Los van dit alles lijkt het mij een goed ontwerpprincipe dat een sessie geen soort van "rijdend archief" is of wordt :p. Bij een sessie mag je best wat selectiever zijn over wat je hier in stopt.

En ook: motivatie voor een oplossing mag best verder gaan dan "efficiëntie" want alles is een tradeoff. Heb je meer van het een dan heb je minder van het ander.

"Ik ga niets beveiligen, want dat is minder efficiënt"

:p
<offtopic>
Grappig, heb je het nu over MySQL? :p
Oke, dat is niet eerlijk, de laatste jaren is het beter geworden, het enige gedrocht is nu MyISAM nog.
</offtopic>
Je maakt goede punten, ik had het niet eloquenter kunnen zeggen.

Reageren