Toon posts:

[php/alg] Persistent (web)data bewaren

Pagina: 1

Acties:

51 views sinds 30-01-2008
Reageer

maandag 27 mei 2002 14:33

Acties:

Verwijderd

Topicstarter

Is dat mogelijk? Ik zou graag willen dat een gebruiker maar 1 keer moet connecteren naar de dbase, tijdens zijn bezoek.

Zo heb ik het getest, maar ik krijg de error: "not a valid MySQL-Link resource"

test.php

code:

<?php
require("dbase.php");

session_start();

$db = new dbase();
$db->connect(1, "localhost", "-", "-", "-");

$_SESSION['dbase'] = $db;

$db->query("SELECT * FROM userlist");
echo $db->num_rows();

echo "<a href=test2.php><br>volgend</a>";
?>

test2.php

code:

<?php
require("dbase.php");

session_start();

$db = new dbase();
$db = $_SESSION['dbase'];

$db->query("SELECT * FROM userlist");
echo $db->num_rows();
?>

Is dit mogelijk? Want verder heb ik geen idee hoe het dan wel zou moeten (ik heb ook wat geknoeid met serialize() functie, maar dat gaf hetzelfde resultaat).

En een korte vraag in verband met dit: is het een goed idee om objecten (inhoud dus) op te slaan in een sessie? Bijvoorbeeld css stijlen (die ik dus de eerste keer uit dbase haal), persoonlijke instellingen (idem), etc...

maandag 27 mei 2002 14:39

Acties:

Verwijderd

euhm je gebruikt een class.... maar weet die wel dat ie met mysql moet verbinden? print eens wat foutmeldingen?

denk dat je geen verbinding krijgt met je db ofzo...
de fout zit hem in die class denk ik

edit: volgens mij heb ik nie goed opgelet

sollie

maandag 27 mei 2002 14:40

Acties:

thomaske

» » » » » »

gebruik je persistent connecties?

[edit]

mysql_pconnect ipv mysql_connect

Brusselmans: "Continuïteit bestaat niet, tenzij in zinloze vorm. Iets wat continu is, is obsessief, dus ziekelijk, dus oninteressant, dus zinloos."

maandag 27 mei 2002 14:53

Acties:

Verwijderd

Topicstarter

Op maandag 27 mei 2002 14:39 schreef woeitje het volgende:
edit: volgens mij heb ik nie goed opgelet sollie

volgens mij ook, maar voor iedereen: de connectie gebeurt dus in test.php

maandag 27 mei 2002 14:54

Acties:

Verwijderd

Topicstarter

Op maandag 27 mei 2002 14:40 schreef thomaske het volgende:
gebruik je persistent connecties?

[edit]

mysql_pconnect ipv mysql_connect

Ja doe ik, ik gebruik pconnect.. maar ik moet nog steeds opnieuw connecteren in "nieuwe" files.

maandag 27 mei 2002 14:55

Acties:

chem

Reist de wereld rond

ja, en?
dat is heel normaal hoor - je link word nog steeds afgesloten (!) aan het einde van je script, maar PHP houd daar nog een 'pool' tussen van links zodat ze hergebruikt kunnen worden.
Connecten is trouwens razendsnel gedaan, en het op deze manier hergebruiken van links lijken me flink grote problemen kunnen opleveren

Klaar voor een nieuwe uitdaging.

maandag 27 mei 2002 15:04

Acties:

ACM

Software Architect

Werkt hier

Op maandag 27 mei 2002 14:55 schreef chem het volgende:
Connecten is trouwens razendsnel gedaan, en het op deze manier hergebruiken van links lijken me flink grote problemen kunnen opleveren

Maar dat geldt dan wel alleen voor mysql

Niet voor oracle en de andere 'serieuze' databases.

Poolen van de connecties loopt overigens niet helemaal middels een pool, het is meer zo dat elke apache thread een connectie opent en openhoudt.

maandag 27 mei 2002 15:07

Acties:

Gomez12

Lijkt me leuk als je je connecties open laat staan en mensen starten hun browser de hele tijd opnieuw op, nieuwe sessies en dus als je je mysql timeout niet heel kort zet heb je op een gegeven moment ook 10.000 connecties, heel leuk

maandag 27 mei 2002 15:08

Acties:

ACM

Software Architect

Werkt hier

Ach en sowieso kan het, bij mijn weten, niet in een php-sessie.

Dat zijn tenslotte 'dode, niet actieve stukken data'. Resourceid's zijn alleen maar 'zinvolle dingen' als de resource er nog is en die blijft echt niet bestaan hoor

maandag 27 mei 2002 15:15

Acties:

Verwijderd

Topicstarter

Ha, het kan dus niet

jammer! Ach, het was het proberen waard he

En over mijn tweede vraag?

En een korte vraag in verband met dit: is het een goed idee om objecten (inhoud dus) op te slaan in een sessie? Bijvoorbeeld css stijlen (die ik dus de eerste keer uit dbase haal), persoonlijke instellingen (idem), etc...

Want het lijkt mij nogal dom om per "page click" opnieuw alle settings uit de mysql dbase te gaan halen, want die veranderen toch nooit.

Of zijn daar betere (snellere?) oplossingen voor?

maandag 27 mei 2002 15:31

Acties:

ACM

Software Architect

Werkt hier

Waarom staan css-files in je database

Maar je kan prima objecten in sessie's opslaan hoor.

maandag 27 mei 2002 15:39

Acties:

Verwijderd

Topicstarter

Op maandag 27 mei 2002 15:31 schreef ACM het volgende:
Waarom staan css-files in je database

Niet echt de hele css files, maar zaken als tekstkleuren, achtergrondkleuren, .. die de gebruiker zelf kan instellen zoals hij zelf wilt (beetje zoals skins).
Ik heb die in de dbase gezet, omdat dat volgens mij makkelijker te editen is. Nu hoef ik gewoon de waarden uit de dbase halen (en er later terug instappen), ipv. de gebruiker een file voorschotelen die ze eventueel helemaal kunnen verkloten.

Maar je kan prima objecten in sessie's opslaan hoor.

Goed! Dan doe ik het zo

Wat is dan het beste/snelste?

(1) Per visit (dus eenmaal) de hele informatie uit de dbase halen, en in het object stoppen en daarna dat object (met inhoud) in een sessie gooien.

of

(2) Het object saven (met de functie serialize();) in een file en weer bij elke visit simpelweg unserialize doen, en zo het object vullen en in een sessie gooien. En natuurlijk als er iets verandert het hele verhaaltje opnieuw doen.

of

(3) Het object saven, en die opslaan in de dbase, en voor de rest hetzelfde als (2). Dus alles zoals bij (2), maar dan in de dbase.

Volgens mij is (3) het beste, misschien iets trager als (2) (files), maar het is makkelijker om backups te maken, en alles overzichtelijk te houden. Zie ik het goed? Alleen maak ik bij (2) en (3) een soort "mirrortje", omdat de losse informatie eveneens in de dbase staat.

dinsdag 28 mei 2002 18:35

Acties:

Verwijderd

Topicstarter

Wat zou het beste zijn?

dinsdag 28 mei 2002 19:15

Acties:

Verwijderd

Op maandag 27 mei 2002 15:07 schreef Gomez12 het volgende:
Lijkt me leuk als je je connecties open laat staan en mensen starten hun browser de hele tijd opnieuw op, nieuwe sessies en dus als je je mysql timeout niet heel kort zet heb je op een gegeven moment ook 10.000 connecties, heel leuk

volgens mij snap jij het niet helemaal.
Connecties open laten staan?
De enige connecties die met pconnects open blijven staan zijn de connecties tussen de Apache childs en de MySQL server. Deze blijven open staan zolang de child leeft. Elke child heeft maximaal 1 connectie per MySQL server.

Je mag zoveel browsers starten als je wilt maar dat wil toch niet zeggen dat het PHP script nog draait? Als het script gedraait heeft is Apache klaar met je en de child wacht dan op de volgende request.

dinsdag 28 mei 2002 20:02

Acties:

WouZz

Elvis is alive!

Op maandag 27 mei 2002 15:08 schreef ACM het volgende:
Ach en sowieso kan het, bij mijn weten, niet in een php-sessie.

Kan inderdaad niet:

Note: It is not currently possible to register resource variables in a session. For example, you can not create a connection to a database and store the connection id as a session variable and expect the connection to still be valid the next time the session is restored. PHP functions that return a resource are identified by having a return type of resource in their function definitions. A list of functions that return resources are available in the resource types appendix.

Hmmz.. "currently"..

On track

dinsdag 28 mei 2002 23:00

Acties:

Verwijderd

Topicstarter

Ja, dat zag ik verkeerd en ik snap nu dat het niet kan/geen goed idee is... maar ik bedoelde nu over classes in het algemeen meegeven, hoe ik dat het best doe. Ik wou dus graag een antwoord op die vraag

woensdag 29 mei 2002 01:58

Acties:

Verwijderd

Op maandag 27 mei 2002 15:39 schreef DiEana het volgende:

[..]

Niet echt de hele css files, maar zaken als tekstkleuren, achtergrondkleuren, .. die de gebruiker zelf kan instellen zoals hij zelf wilt (beetje zoals skins).
Ik heb die in de dbase gezet, omdat dat volgens mij makkelijker te editen is. Nu hoef ik gewoon de waarden uit de dbase halen (en er later terug instappen), ipv. de gebruiker een file voorschotelen die ze eventueel helemaal kunnen verkloten.

Het zou mijns inziens sneller/makkelijker zijn om een aantal standaard skins aan te bieden, waaruit de gebruiker kan kiezen. Bij iedere skin hort dan 1 CSS file, em klaar is kees.

[..]

Goed! Dan doe ik het zo

Wat is dan het beste/snelste?

(1) Per visit (dus eenmaal) de hele informatie uit de dbase halen, en in het object stoppen en daarna dat object (met inhoud) in een sessie gooien.

of

(2) Het object saven (met de functie serialize();) in een file en weer bij elke visit simpelweg unserialize doen, en zo het object vullen en in een sessie gooien. En natuurlijk als er iets verandert het hele verhaaltje opnieuw doen.

of

(3) Het object saven, en die opslaan in de dbase, en voor de rest hetzelfde als (2). Dus alles zoals bij (2), maar dan in de dbase.

Volgens mij is (3) het beste, misschien iets trager als (2) (files), maar het is makkelijker om backups te maken, en alles overzichtelijk te houden. Zie ik het goed? Alleen maak ik bij (2) en (3) een soort "mirrortje", omdat de losse informatie eveneens in de dbase staat.

Wat het beste / snelste is, is ontzettend afhankelijk van omstandigheden.

Sessies "kosten" relatief veel geheugen, zeker als je veel gebruikers tegelijkertijd hebt. Als je geheugen volloopt, zal de performance dus door de bodem gaan.

Verder zijn sessies vergankelijk (denk aan een web server restart, dus je moet zorgen dat eventuele wijzigingen van de gebruiker wel gesynchroniseerd worden met de database. Ook zijn PHP sessies server gebonden, dus in een mutli-server applicatie niet te gebruiken, tenzij ze eventueel ook persistent te maken zijn in een centrale database.

Naar file schrijven en weer ophalen is absoluut een slecht idee. Disk access is relatief onbetrouwbaar en langzaam.

Een object naar een database schrijven en ophalen kan gunstig zijn als het ophalen van alle gegevens voor het object heel veel tijd kost. Als dat niet zo is, is het een zinloze aktie, aangezien het wegschrijven over het algemeen veel intensiever is dan het ophalen, dus verlies je performance. Als je echter in een multi-server omgeving zit is dit weer heel anders, en zijn database-persistent sessies juist een goede zaak om schaalbaarheid te verkrijgen, hoewel dit wel zeer zware eisen aan je database server stelt.

Kortom, dit is een niet eenvoudig te beantwoorden vraag. Uitgaande dat dit echter een niet al te grote noch bedrijfskritische operatie is, zou ik alle gegevens gewoon in sessie laten staan, en zorgen dat de sessie time-out redelijk klein is om geheugen te sparen.

HTH

zaterdag 1 juni 2002 16:22

Acties:

Verwijderd

Topicstarter

Sorry voor de late reply, heb het enorm druk gehad de laatste 4 dagen.. excuses

Op woensdag 29 mei 2002 01:58 schreef MrX het volgende:

[..]

Het zou mijns inziens sneller/makkelijker zijn om een aantal standaard skins aan te bieden, waaruit de gebruiker kan kiezen. Bij iedere skin hort dan 1 CSS file, em klaar is kees.
[..]

Dat is een oplossing ja, maar CSS was maar een voorbeeld, er is natuurlijk meer. Ik noem bijvoorbeeld: userrights ophalen, userinformatie, visits, ...

Wat het beste / snelste is, is ontzettend afhankelijk van omstandigheden.

Sessies "kosten" relatief veel geheugen, zeker als je veel gebruikers tegelijkertijd hebt. Als je geheugen volloopt, zal de performance dus door de bodem gaan.

Het spijtige is dat ik de server zelf niet kan beheren.. dus ik kan niet aan die instellingen gaan. Waarschijnlijk worden de standaardinstellingen gebruikt. Heb je daar wat meer info over?

Verder zijn sessies vergankelijk (denk aan een web server restart, dus je moet zorgen dat eventuele wijzigingen van de gebruiker wel gesynchroniseerd worden met de database.

Ja dat is nu ook net de bedoeling: Ik haal alleen de gegevens op (waarvan ik er enkele bovenaan genoemd heb) bij het begin van een visit. Die gegevens sla ik dus op in een object, en dat object sla ik op in een sessie. Dit heeft (volgens mij) als voordeel dat de dbase minder belast wordt (want ik moet niet per click al die zooi opnieuw gaan leeghalen) en het dus allemaal veel sneller zou moeten gaan.

Ook zijn PHP sessies server gebonden, dus in een mutli-server applicatie niet te gebruiken, tenzij ze eventueel ook persistent te maken zijn in een centrale database.

Daar heb ik ook aan gedacht, maar daar stuitte ik op een probleem: stel ik sla al die objecten (CSS..) op in een dbase (na serialize() etc.. functies) in een string ofzo, en dus niet zoals ik eerst van plan was: gewoon in tabellen&rows. Het voordeel is dan dat ik die objecten simpelweg hoef neer te halen uit de dbase bij het begin van een visit, en niet meer zelf hoef samen te stellen. Die objecten editen enzo is niet moeilijk: je haalt ze neer, je wijzigt object inhoud, en je slaat ze terug op. Maar stel nu voor dat ik plots beslis om een extra 'field' te maken in het object: (bijvoorbeeld 'background-color') omdat ik dat ook instelbaar wil maken voor de gebruikers. Dan worden ineens alle objecten in de dbase ongeldig, omdat die dat field nog niet bevatten? En verliest dus ook iedereen zijn instellingen?

Naar file schrijven en weer ophalen is absoluut een slecht idee. Disk access is relatief onbetrouwbaar en langzaam.

Ja, dat dacht ik al :\

Een object naar een database schrijven en ophalen kan gunstig zijn als het ophalen van alle gegevens voor het object heel veel tijd kost. Als dat niet zo is, is het een zinloze aktie, aangezien het wegschrijven over het algemeen veel intensiever is dan het ophalen, dus verlies je performance. Als je echter in een multi-server omgeving zit is dit weer heel anders, en zijn database-persistent sessies juist een goede zaak om schaalbaarheid te verkrijgen, hoewel dit wel zeer zware eisen aan je database server stelt.

Met dat wegschrijven, daarmee bedoel je toch wegschrijven naar de dbase hé? Dat hoef ik toch niet te doen? Alles staat al in de dbase, ik haal alles neer, en gooi alles in objecten. Als er iets aangepast moet worden (wat dus zelden is), doe ik dat rechtstreeks in de dbase.

Kortom, dit is een niet eenvoudig te beantwoorden vraag. Uitgaande dat dit echter een niet al te grote noch bedrijfskritische operatie is, zou ik alle gegevens gewoon in sessie laten staan, en zorgen dat de sessie time-out redelijk klein is om geheugen te sparen.

Ok, bedankt voor de uitleg

HTH

zaterdag 1 juni 2002 16:35

Acties:

Verwijderd

Overigens vond ik net per ongeluk een speciale Session / State management deamon, die, vanuit een extensie van PHP, aangeroepen kan worden, en waarvoor er ook een PostgreSQL backend wordt gebouwd om het persistent te maken, zodat je persistent sessies over een groep PHP servers kan gebruiken.

Het heet Msession. Zie:
- http://www.php.net/manual/en/ref.msession.php
- http://www.mohawksoft.com/phoenix/msession.html

zaterdag 1 juni 2002 16:38

Acties:

Verwijderd

Topicstarter

Op zaterdag 01 juni 2002 16:35 schreef MrX het volgende:
Overigens vond ik net per ongeluk een speciale Session / State management deamon, die, vanuit een extensie van PHP, aangeroepen kan worden, en waarvoor er ook een PostgreSQL backend wordt gebouwd om het persistent te maken, zodat je persistent sessies over een groep PHP servers kan gebruiken.

Het heet Msession. Zie:
- http://www.php.net/manual/en/ref.msession.php
- http://www.mohawksoft.com/phoenix/msession.html

Daar ben ik ook al eens op uitgekomen, ziet er wel interessant uit, maar ik kan spijtig genoeg niets aan de server instellingen veranderen... en dat moet hier dus wel bij

EDIT: Hmm, eigenlijk heeft de titel (SQL connecties..) niet meer zo erg veel te maken met de huidige discussie: hoe het efficiënste statische, maar dan toch weer dynamische data opslaan/bijhouden. Modje?

zaterdag 1 juni 2002 17:05

Acties:

ACM

Software Architect

Werkt hier

Op woensdag 29 mei 2002 01:58 schreef MrX het volgende:
Wat het beste / snelste is, is ontzettend afhankelijk van omstandigheden.

Sessies "kosten" relatief veel geheugen, zeker als je veel gebruikers tegelijkertijd hebt. Als je geheugen volloopt, zal de performance dus door de bodem gaan.

Verder zijn sessies vergankelijk (denk aan een web server restart, dus je moet zorgen dat eventuele wijzigingen van de gebruiker wel gesynchroniseerd worden met de database. Ook zijn PHP sessies server gebonden, dus in een mutli-server applicatie niet te gebruiken, tenzij ze eventueel ook persistent te maken zijn in een centrale database.

Naar file schrijven en weer ophalen is absoluut een slecht idee. Disk access is relatief onbetrouwbaar en langzaam.

In php is de default sessionhandler een file-based-sessie handler met PER sessie een aparte file.
Een server reboot/restart heeft dus geen invloed daarop, de nadelen van opslaan in files gelden natuurlijk wel

Er is ook een mm-sessionhandler (shared memory ding met de mm-extentie) maar die heb ik zelf nooit gebruikt.

Op zaterdag 01 juni 2002 16:35 schreef MrX het volgende:
Het heet Msession. Zie:

Die had ik idd ook al es gezien en overwogen, ik ben altijd wel een beetje sceptisch met 'beta' versies (ookal willen de stabielste linux-pijlers ook nog wel eens beta zijn

)

zaterdag 1 juni 2002 17:05

Acties:

ACM

Software Architect

Werkt hier

topictitel zo beter?

zaterdag 1 juni 2002 17:10

Acties:

Verwijderd

ik zie niet in waarom je dat niet met de db wil doen.

als die db localhost draait gaat ie evensnel als met files ( mogelijk zelfs sneller )
pas als ie extern staat zou je kunnen overwegen om het tijdelijk op te slaan, wegens bandbreedte gebruik etc.

maar ik raad aan die styles lekker in de database te laten staan, gaat snel zat zo

zaterdag 1 juni 2002 17:17

Acties:

Verwijderd

Op zaterdag 01 juni 2002 17:10 schreef TheViP het volgende:
ik zie niet in waarom je dat niet met de db wil doen.

als die db localhost draait gaat ie evensnel als met files ( mogelijk zelfs sneller )
pas als ie extern staat zou je kunnen overwegen om het tijdelijk op te slaan, wegens bandbreedte gebruik etc.

maar ik raad aan die styles lekker in de database te laten staan, gaat snel zat zo

Even nadenken ... stel, je hebt gegevens in het geheugen (een sessie) of gegevens op disk (database, hoewel door caching het theoretisch ook in het geheugen zou kunnen staan) ... wat zou dan sneller zijn?

zaterdag 1 juni 2002 17:19

Acties:

ACM

Software Architect

Werkt hier

Op zaterdag 01 juni 2002 17:17 schreef MrX het volgende:
Even nadenken ... stel, je hebt gegevens in het geheugen (een sessie) of gegevens op disk (database, hoewel door caching het theoretisch ook in het geheugen zou kunnen staan) ... wat zou dan sneller zijn?

Is niet te zeggen zonder meer info

Als je direct weet welke page het op disk staat (oftewel, er is een goede index) kan het best dat het sneller is dan 100MB geheugen afzoeken (als daar dus geen goede 'index' is).

Maar in de meeste gevallen zal dat geheugen sneller toegankelijk zijn.

[edit]
Vergeet echter niet dat php default met file-storage werkt voor sessies he?

zaterdag 1 juni 2002 17:21

Acties:

Verwijderd

Op zaterdag 01 juni 2002 17:17 schreef MrX het volgende:

[..]

Even nadenken ... stel, je hebt gegevens in het geheugen (een sessie) of gegevens op disk (database, hoewel door caching het theoretisch ook in het geheugen zou kunnen staan) ... wat zou dan sneller zijn?

mysql.

waarom ? omdat sessies ook als textbestanden worden opgeslagen

check /tmp ofzo maar eens

daartegenover staat mysql die zo slim gebouwd is dat ie dit soort dingen cached, in, jawel, het geheugen. ( meende ik..)

en mysql heeft dan als voordeel dat ie voldynamisch is, inplaats van de sessie die nooit word geupdate.

andere mogelijkheid is het wegschrijven naar een bestand in de docroot, en daar naartoe linken als zijnde de CSS file.

zaterdag 1 juni 2002 17:22

Acties:

ACM

Software Architect

Werkt hier

Op zaterdag 01 juni 2002 17:21 schreef TheViP het volgende:
waarom ? omdat sessies ook als textbestanden worden opgeslagen

Jij haalt nu het algemene principe van sessies en 'sessies in php' door elkaar

zaterdag 1 juni 2002 17:27

Acties:

Verwijderd

Op zaterdag 01 juni 2002 17:22 schreef ACM het volgende:

[..]

Jij haalt nu het algemene principe van sessies en 'sessies in php' door elkaar

?
we gaan toch niet de theorie achter sessies zoeken he ?

ik weet alleen van vBulletin dat ie die zooi lekker in de db opslaat, en dat dat vlot genoeg gaat. waarom heel moeilijk doen als je gewoon een leuke db achter je site hebt hangen ?

zaterdag 1 juni 2002 17:30

Acties:

Verwijderd

Sessies in PHP op disk??????????????????????????
/me grumbles
/me gooit PHP in de sloot
|:(|:(|:(|:(|:(|:(|:(|:(|:(

edit:
/me zou zijn eigen links wat beter moeten lezen, want in de tut. op zend.com stond:[quote]
Storage Modules

To read and save session data, PHP uses storage modules, thus abstracting the back end of the library. There are currently three storage modules available:
Files. By default, PHP uses the files module to save the session data to disk. It creates a text file named after the session ID in /tmp. You probably won't ever need to access this file directly. In the example of the session counter, the content of this file would look like this, which is a serialized representation of the variable: counter|i:4;

Memory managed. If you need higher performance, the mm module is a viable alternative; it stores the data in shared memory and is therefore not limited by the hardware I/O system.

User. Used internally to realize user-level callback functions that you define with session_set_save_handler().

The real power lies in the capacity to specify user callbacks as storage modules. Because you can write your functions to handle sessions while still being able to rely on the standardized PHP API, you can store sessions wherever and however you want: in a database like MySQL, XML files, on a remote FTP server (an FTP server is unlikely, but you get the idea).
[/quote]

Oftewel:
1) default in files

2) kan wel in geheugen

Overigens ...

Op zaterdag 01 juni 2002 17:19 schreef ACM het volgende:
Als je direct weet welke page het op disk staat (oftewel, er is een goede index) kan het best dat het sneller is dan 100MB geheugen afzoeken (als daar dus geen goede 'index' is).

Ieder zinvol memory based session systeem zal nooit langzamer zijn dan een DB Access, aangezien het doel van een sessie systeem is om gegevens snel beschikbaar te maken in geheugen, niet om gegevens in het geheugen te stoppen en hopen dat je het vindt.

Op het ogenblik dat het geheugen volloopt en de machine gaat trashen, is het redelijkerwijs te verwachten dat zowel je DB als je sessie systeem daaronder lijdt. Misschien zal in die omstandigheden de DB het winnen, maar dan heb je duidelijk je app niet goed getuned of niet voldoende hardware / scalability voor je applicatie.

Op zaterdag 01 juni 2002 17:32 schreef TheViP het volgende:
enig idee hoeveel sessies mensen kunnen maken op hun sites ?en ook hoe GROOT ze soms zijn ( zie dit topic, even de css erin opslaan... en dat voor elke gebruiker dan ook nog eens een keer )

geloof mij, als je sessies echt allemaal wil opslaan in ram, dan moeten heel wat webservers een geheugen uitbreiding hebben

Inderdaad, niet onder alle gevallen wil je sessies in het geheugen opslaan, bijv. als die onzinnig groot zijn, of onzinnig lang open blijven staan. Veel geheugen is dan ook een must voor een serieuze webserver.

zaterdag 1 juni 2002 17:32

Acties:

Verwijderd

Op zaterdag 01 juni 2002 17:30 schreef MrX het volgende:
Sessies in PHP op disk??????????????????????????
/me grumbles
/me gooit PHP in de sloot
|:(|:(|:(|:(|:(|:(|:(|:(|:(

enig idee hoeveel sessies mensen kunnen maken op hun sites ?en ook hoe GROOT ze soms zijn ( zie dit topic, even de css erin opslaan... en dat voor elke gebruiker dan ook nog eens een keer )

geloof mij, als je sessies echt allemaal wil opslaan in ram, dan moeten heel wat webservers een geheugen uitbreiding hebben

zaterdag 1 juni 2002 17:33

Acties:

Verwijderd

Topicstarter

ACM: topic titel is veel beter, bedankt!

Maareuh, wat ik nu wil weten: het kan toch niet zijn dat 'per click' alle informatie uit de mysql dbase halen sneller is dan 'eenmaal' (op het begin dus) alles neerhalen, en dat dan allemaal (in een object best, voor de eenvoud) op te slaan in een sessie?

Alle informatie: dingen die niet kunnen veranderen tijdens een visit, behalve als de user het zelf wil (en dan refresh ik dus ook de sessie inhoud). Dus personlijke instellingen zeg maar.

zaterdag 1 juni 2002 17:34

Acties:

Verwijderd

Topicstarter

Op zaterdag 01 juni 2002 17:32 schreef TheViP het volgende:

[..]

enig idee hoeveel sessies mensen kunnen maken op hun sites ?en ook hoe GROOT ze soms zijn ( zie dit topic, even de css erin opslaan... en dat voor elke gebruiker dan ook nog eens een keer )

geloof mij, als je sessies echt allemaal wil opslaan in ram, dan moeten heel wat webservers een geheugen uitbreiding hebben

Klinkt dat sceptisch tov. mijn idee? Ik ga natuurlijk 'standaard' CSS formules maken, en die ga ik natuurlijk niet opslaan per gebruiker.

CSS was zo te zien een slecht voorbeeld

Laten we het houden op 'persoonlijke instellingen'

zaterdag 1 juni 2002 17:36

Acties:

Verwijderd

DiEana: in dat geval is het zeker een mogelijkheid.
maar ik denk dat je de snelheids winst niet eens kan benchmarken, daarvoor is mysql gewoon te snel.

je moet zelf maar zien watje wil doen, beide opties zijn reeel te gebruiken (WAT IS DE TOETS VAN ZON E MET " EROP ??)

zaterdag 1 juni 2002 17:39

Acties:

Verwijderd

Topicstarter

Op zaterdag 01 juni 2002 17:36 schreef TheViP het volgende:
DiEana: in dat geval is het zeker een mogelijkheid.
maar ik denk dat je de snelheids winst niet eens kan benchmarken, daarvoor is mysql gewoon te snel.

Het komt gewoon zo achterlijk over: opnieuw en opnieuw dezelfde data neerpleuren, hoewel je 100% garantie hebt dat er niets aan veranderd is.

je moet zelf maar zien watje wil doen, beide opties zijn reeel te gebruiken (WAT IS DE TOETS VAN ZON E MET " EROP ??)

ë ?

zaterdag 1 juni 2002 17:42

Acties:

Verwijderd

Op zaterdag 01 juni 2002 17:39 schreef DiEana het volgende:
ë ?

die jah

zaterdag 1 juni 2002 18:10

Acties:

mocean

Sommige (kleinere) zaken kan je ook opslaan in cookies, bijvoorbeeld de usergegevens zoals naam etc, maar ook bijvoorbeeld de skin/stylesheet die iemand wil.

Eventueel kan je daar dan ook met javascript bij meen ik, heb je er helemaal geen last meer van op je server.

Koop of verkoop je webshop: ecquisition.com

zaterdag 1 juni 2002 18:25

Acties:

Verwijderd

Topicstarter

Op zaterdag 01 juni 2002 18:10 schreef mocean het volgende:
Sommige (kleinere) zaken kan je ook opslaan in cookies, bijvoorbeeld de usergegevens zoals naam etc, maar ook bijvoorbeeld de skin/stylesheet die iemand wil.

Eventueel kan je daar dan ook met javascript bij meen ik, heb je er helemaal geen last meer van op je server.

Volgens mij wil je echt niet alle usergegevens (naam, e-mail, userid, skin styles, userrights, ...) opslaan in een cookie? Dat geeft volgens mij alleen maar een inconsistente database.

zondag 2 juni 2002 12:35

Acties:

Verwijderd

Als ik het goed begrijp wil je dus eigenlijk de output van de query cachen die de persoonlijke instellingen van een user ophaalt?
Waarom eigenlijk? voor performance? MySQL cached ook al.

Op zaterdag 01 juni 2002 18:25 schreef DiEana het volgende:

Volgens mij wil je echt niet alle usergegevens (naam, e-mail, userid, skin styles, userrights, ...) opslaan in een cookie? Dat geeft volgens mij alleen maar een inconsistente database.

Eerst wil je php sessies gebruiken als cache en een cookie als cache geeft een inconsistente db

zondag 2 juni 2002 12:49

Acties:

Soultaker

Op zondag 02 juni 2002 12:35 schreef peidor het volgende:
Eerst wil je php sessies gebruiken als cache en een cookie als cache geeft een inconsistente db

Het probleem is natuurlijk dat je de gegevens die je uit cookies terugkrijgt niet kunt vertrouwen. Van sessies kun je de integriteit wel garanderen (hoewel het in theorie mogelijk is dat een gebruiker de sessie van een andere gebruiker overneemt).

Wat dit met een database te maken heeft weet ik niet, maar ik kan me wel voorstellen dat je geen cookies wilt gebruiken voor gegevens die aan een bepaalde restrictie moeten voldoen (hoewel je ze bij elke request opnieuw kan checken) of die de client niet mag zien.

zondag 2 juni 2002 13:01

Acties:

Hydra

Op zaterdag 01 juni 2002 17:33 schreef DiEana het volgende:
Maareuh, wat ik nu wil weten: het kan toch niet zijn dat 'per click' alle informatie uit de mysql dbase halen sneller is dan 'eenmaal' (op het begin dus) alles neerhalen, en dat dan allemaal (in een object best, voor de eenvoud) op te slaan in een sessie?

Iedere keer als een pagina geopend wordt waarin sessies gebruikt worden wordt de sessie data gelezen. Standaard PHP sessies gebruiken tekstfiles, en dus wordt bij iedere klik die data uit een aantal tekstfiles opgehaald.

En dit is duurder dan een simpele SELECT query op een DB, ook omdat MySQL dergelijke data netjes in z'n geheugen cached.

https://niels.nu

zondag 2 juni 2002 13:11

Acties:

ACM

Software Architect

Werkt hier

Op zaterdag 01 juni 2002 17:30 schreef MrX het volgende:
Sessies in PHP op disk??????????????????????????
/me grumbles
/me gooit PHP in de sloot
|:(|:(|:(|:(|:(|:(|:(|:(|:(

Gaat het weer een beetje?

Oftewel:
1) default in files
2) kan wel in geheugen

1 -> zei ik toch?
2 -> zei ik toch?

Ieder zinvol memory based session systeem zal nooit langzamer zijn dan een DB Access, aangezien het doel van een sessie systeem is om gegevens snel beschikbaar te maken in geheugen, niet om gegevens in het geheugen te stoppen en hopen dat je het vindt.

Sja, ik zei het ook maar als een zij-note dat het niet per definitie sneller is om ram te gebruiken.
Over het algemeen is dat natuurlijk wel waar anders kan je weer opnieuw achter je ontwerptafel gaan zitten

Op het ogenblik dat het geheugen volloopt en de machine gaat trashen, is het redelijkerwijs te verwachten dat zowel je DB als je sessie systeem daaronder lijdt. Misschien zal in die omstandigheden de DB het winnen, maar dan heb je duidelijk je app niet goed getuned of niet voldoende hardware / scalability voor je applicatie.

De app kan je dan natuurlijk schalen/tunen door de sessies in de DB of op disk op te slaan

Maar aangezien php niet helemaal voor extreem grote sites bedoelt lijkt te zijn en de meeste gebruikers niet de luxe hebben van het vergroten van hun servercapaciteit EN je dat meestal doet dmv meer webservers ipv nog zwaardere kan ik me voorstellen dat je je er niet te druk om moet maken.

Geheugen-sessies kan je niet gebruiken bij een webservercluster en een doos met 4GB geheugen is echt niet zoveel sneller als 2 4 doosjes met 1GB elk (maar wel net zo duur of duurder...)

Zodra je applicatie groot genoeg is dat je je echt druk moet maken om de schaling moet je sowieso niet alleen naar je sessie's kijken maar naar vele andere punten.
En voor schaling is het dan beter en sessie-server/db te gebruiken (danwel inline met je echte db, danwel dedicated).

Inderdaad, niet onder alle gevallen wil je sessies in het geheugen opslaan, bijv. als die onzinnig groot zijn, of onzinnig lang open blijven staan. Veel geheugen is dan ook een must voor een serieuze webserver.

Wanneer is het onzinnig groot?
Wanneer is het onzinnig lang?

zondag 2 juni 2002 13:30

Acties:

brammetje

Op zondag 02 juni 2002 13:01 schreef Hydra het volgende:
Iedere keer als een pagina geopend wordt waarin sessies gebruikt worden wordt de sessie data gelezen. Standaard PHP sessies gebruiken tekstfiles, en dus wordt bij iedere klik die data uit een aantal tekstfiles opgehaald.

En dit is duurder dan een simpele SELECT query op een DB, ook omdat MySQL dergelijke data netjes in z'n geheugen cached.

Tja, als je alle info die je in je sessie wilt stoppen allemaal van 1 punt kan halen dan hoef je dat natuurlijk niet te cachen, zodra je meerdere dingen nodig hebt (rechten/instellingen/noem maar wat) dan zal het wel lonen dit in een class te stoppen, te serealizeren, in een db te stoppen, en later simpel op te halen..

zondag 2 juni 2002 13:31

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 12:49 schreef Soultaker het volgende:

[..]

Het probleem is natuurlijk dat je de gegevens die je uit cookies terugkrijgt niet kunt vertrouwen. Van sessies kun je de integriteit wel garanderen (hoewel het in theorie mogelijk is dat een gebruiker de sessie van een andere gebruiker overneemt).

Wat dit met een database te maken heeft weet ik niet, maar ik kan me wel voorstellen dat je geen cookies wilt gebruiken voor gegevens die aan een bepaalde restrictie moeten voldoen (hoewel je ze bij elke request opnieuw kan checken) of die de client niet mag zien.

Ja dat bedoelde ik.. zo'n dingen (userrights) horen echt niet in een cookie thuis.

En wat dat met een dbase te maken heeft? Ik zocht, zeg maar, een snel alternatief van veel data en cookies

Beetje fout geformuleerd, maar het komt er een (heel klein) beetje op neer

Op zondag 02 juni 2002 13:01 schreef Hydra het volgende:

[..]

Iedere keer als een pagina geopend wordt waarin sessies gebruikt worden wordt de sessie data gelezen. Standaard PHP sessies gebruiken tekstfiles, en dus wordt bij iedere klik die data uit een aantal tekstfiles opgehaald.

En dit is duurder dan een simpele SELECT query op een DB, ook omdat MySQL dergelijke data netjes in z'n geheugen cached.

Dat wou ik doen ja.. Ik wou al die 'persoonlijke' gegevens gaan opslaan in een sessie, bij de eerste click, en alles dan steeds uit de sessie halen ipv. telkens opnieuw alles uit de dbase. Zo te zien is dat niet een goed idee, omdat MySQL toch het meeste reeds indexeert

Nu rest mij nog 1 vraag: wat is sneller:
· per keer (dus per click) alle rows uit x tabellen uit mysql halen
· al die rows de eerste click in een object gooien, dat object bitesgewijs opslaan in de dbase, en ipv. per click alle rows neer te halen, die x objecten uit de dbase gaan halen..die dus alle gegevens in zich heeft.

zondag 2 juni 2002 13:35

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 13:30 schreef brammetje het volgende:

[..]

Tja, als je alle info die je in je sessie wilt stoppen allemaal van 1 punt kan halen dan hoef je dat natuurlijk niet te cachen, zodra je meerdere dingen nodig hebt (rechten/instellingen/noem maar wat) dan zal het wel lonen dit in een class te stoppen, te serealizeren, in een db te stoppen, en later simpel op te halen..

DAT bedoelde ik dus! Het gaat hier niet om '1 punt' (1 tabel bedoel je?), maar echt een stuk of 5. Ik noem maar: persoonlijke instellingen, userrights, CSS instellingen, omgevingsvariabelen, ... Die zaken staan dus niet in 1 tabel.

En dat vroeg ik me dus af :): 5 'kleine' queries uit 5 tabellen, of 1 grotere query die een object (of meerdere) haalt uit 1 tabel, waar alles instaat dat je nodig hebt met daarbij eventueel (als het nodig is: als de gebruiker iets verandert heeft) eenmaal (de eerste click) een INSERT/UPDATE querie natuurlijk.

Het enige nadeel dat ik zie is dat je database er een stukje groter op wordt, afhankelijk van het aantal inglogde users? (een vijftal tamelijk grote strings per user?)

zondag 2 juni 2002 14:27

Acties:

Verwijderd

Op zondag 02 juni 2002 13:11 schreef ACM het volgende:
Gaat het weer een beetje?

/me is immiddels al weer helemaal afgekoeld, zelfs met deze temperaturen ...

1 -> zei ik toch?
2 -> zei ik toch?

Van 1 wist ik dat je dat zei, van 2 had ik dat eerlijk gezegd over het hoofd gezien.

Sja, ik zei het ook maar als een zij-note dat het niet per definitie sneller is om ram te gebruiken.
Over het algemeen is dat natuurlijk wel waar anders kan je weer opnieuw achter je ontwerptafel gaan zitten

Idd.

De app kan je dan natuurlijk schalen/tunen door de sessies in de DB of op disk op te slaan

Woah ... lijkt me een leuke om in je ap de geheugengebruik te gaan meten en run-time te gaan tunen ... kanppe vent om dat echt goed te laten werken! Da's zo eentje voor in de categorie "leuke uitdaging".

Maar aangezien php niet helemaal voor extreem grote sites bedoelt lijkt te zijn en de meeste gebruikers niet de luxe hebben van het vergroten van hun servercapaciteit EN je dat meestal doet dmv meer webservers ipv nog zwaardere kan ik me voorstellen dat je je er niet te druk om moet maken.

Geheugen-sessies kan je niet gebruiken bij een webservercluster en een doos met 4GB geheugen is echt niet zoveel sneller als 2 4 doosjes met 1GB elk (maar wel net zo duur of duurder...)

Zodra je applicatie groot genoeg is dat je je echt druk moet maken om de schaling moet je sowieso niet alleen naar je sessie's kijken maar naar vele andere punten.
En voor schaling is het dan beter en sessie-server/db te gebruiken (danwel inline met je echte db, danwel dedicated).

PHP kan absoluut voor high performance, scalable web-sites gebruikt worden. Veel grote systemen worden echter tegenwoordig gebouwd op basis van application servers die de complexiteiten die dit met zich meebrengt opvangen door een slimme architectuur, zodat de ontwikkelaar er niet zo heel veel mee bezig hoeft te houden. Als je van scratch een systeem bouwt, moet je al dit sooft afwegingen zelf maken, en daardoor wordt het bouwen een stuk minder triviaal als het anders geweest zou zijn.

Als in een systeem onderdelen van dit systeem redelijk makkelijk onder te verdelen zijn over verschillende machines, dan is dit natuurlijk de eerste stap om meer performance te krijgen. Denk daarbij aan een losse database en web server. Dit zou ik niet onder 'scalability' willen plaatsen, aangezien je op een dergelijke wijze niet onbeperkt nieuwe hardware kan blijven toevoegen om zo betere performance te krijgen.

Zodra je echter meerdere machines in een cluster krijgt die dezelfde funktie vervullen (zoals 2 webservers), wordt het al snel wat meer tricky. Scalability is dan noodzakelijk, maar zal ook over het algemeen een hoge performance penalty met zich meebrengen, en vaak het systeem complexer maken. Aan de andere kant stelt dit je wel in staat om ook high availability in te bouwen, iets wat bij dergelijke zware applicaties vaak gewenst is.

Echter, omdat een (bestaande) applicatie scalable maken zo tricky is zal men in het algemeen kiezen om de applicatie zo veel mogelijk te tunen. In-memory sessies, en aparte machines voor web- en DB-server zijn dan allebei goede stappen om het allemaal nog iets langer te rekken.

Overigens zijn hardwarekosten, zeker op x86 server technologie, zelden een groot issue in dergelijke zaken, aangezien kosten voor het aanpassen van software relatief een groter deel van het budget in beslag nemen.

Met een cluster webservers is het inderdaad sterk aan te raden om sessie handling via een centrale deamon te doen, zoals bijv. ondersteund wordt door de Msession functies

Wanneer is het onzinnig groot?
Wanneer is het onzinnig lang?

Da's een kwestie van performance testing. Gebruik daarvoor een toal als Astra Load Test, stel een aantal scenario's op, en kijk hoeveel geheugen er door de sessies gebruikt gaat worden, en of dat een probleem wordt.

Soms kan een simpel rekensommetje zelfs al helpen. Bijv. stel dat je op piektijden zo'n 50 pagina-clicks per minuut hebt. Je sessie time-out staat om 30 minuten. Dan staan er dus op die tijden gemiddeld 50 * 30 =1500 sessies open. Stel dat een sessie ongeveer 20 KB in beslag neemt, dan kost dat ongeveel 30000 KB oftwel ongeveer 30 MB. Ga daarna eens met de cijfers spelen (Stel, ik stop 3 keer zoveel gegevens in mijn sessie, wat gebeurt er dan?) en je krijgt een goed gevoel voor waar de knelpunten komen te liggen.

Overigens heb ik het gevoel dat jij waarschijnlijk 90% van mijn gelul wel weet, maar hopelijk zijn er dan andere mensen die er iets aan hebben.

Anyway, enjoy

zondag 2 juni 2002 14:28

Acties:

Hydra

Op zondag 02 juni 2002 13:31 schreef DiEana het volgende:
· per keer (dus per click) alle rows uit x tabellen uit mysql halen
· al die rows de eerste click in een object gooien, dat object bitesgewijs opslaan in de dbase, en ipv. per click alle rows neer te halen, die x objecten uit de dbase gaan halen..die dus alle gegevens in zich heeft.

Een de data uit een DB bijmekaar sprokkelen en dat weer opslaan is een beetje onzinnig, en bovendien krijg je op die manier geheid problemen als instellingen wijzigen.

Een select is razendsnel, mits je de juiste indices aangelegd hebt natuurlijk. Ik zou dus gewoon voor optie 1 gaan.

https://niels.nu

zondag 2 juni 2002 14:52

Acties:

Verwijderd

Topicstarter

[quote]
Op zondag 02 juni 2002 14:28 schreef Hydra het volgende:

[..]

Een de data uit een DB bijmekaar sprokkelen en dat weer opslaan is een beetje onzinnig, en bovendien krijg je op die manier geheid problemen als instellingen wijzigen.
[quote]

Ja maar dat gebeurt maar 1x in de "zoveel tijd". Dus je verandert alleen het object in de dbase als de gebruiker er ook om vraagt hé. Het is echt onwaarschijnlijk dat CSS stijlen, userrights meermaals per dag (week?) veranderen. Dus dat is maar 'éénmalig'?

Een select is razendsnel, mits je de juiste indices aangelegd hebt natuurlijk. Ik zou dus gewoon voor optie 1 gaan.

Tuurlijk ja

Ik denk dat ik het zo ga doen:

Ik maak een extra tabel aan, met daar alle objecten in van elke gebruiker. Dus per soort object een ander string-veld.
Dan ga ik in cookies variabelen zetten als 'useCSSObject', 'useUserrightsObject', ...
Zijn die variabelen 1: Ik haal het object simpelweg neer uit die extra tabel, unserialize het en 'kopieer' het over in mijn object in de php scripts.
Zijn die variabelen 0: Ik sync die extra tabel (dus ik maak de objecten in die extra tabel up to date), en ondertussen doe ik hetzelfde als in mogelijkheid 1.

De voordelen volgens mij:
· het zou volgens mij veel sneller moeten gaan, en de dbase wordt minder belast? (x queries uit x tabellen tov. 1 querie uit 1 tabel). mogelijkheid 2 gaat echt niet al te vaak voorkomen: eenmaal die instellingen gezet, blijft de gebruiker daar normaal gezien af voor een lange tijd?
· in de cookies staat geen gevoelige informatie: de gebruiker zal geen vershil merken tussen 'useObject 1' of 'useObject 0'.
· de implementatie wordt volgens mij veel simpeler?

zondag 2 juni 2002 14:57

Acties:

Hydra

Op zondag 02 juni 2002 14:52 schreef DiEana het volgende:
De voordelen volgens mij:
· het zou volgens mij veel sneller moeten gaan, en de dbase wordt minder belast? (x queries uit x tabellen tov. 1 querie uit 1 tabel).

Hmm. Je weet wat een join doet?

Om de userinfo op te halen, zou je maar 1 query nodig moeten hebben. Als dat niet zo is, zit er een fout in je DB ontwerp

https://niels.nu

zondag 2 juni 2002 15:04

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 14:57 schreef Hydra het volgende:

[..]

Hmm. Je weet wat een join doet? Om de userinfo op te halen, zou je maar 1 query nodig moeten hebben. Als dat niet zo is, zit er een fout in je DB ontwerp

Ja ik weet wat een join doet

Bijv een "1 op veel relate" bij een kalender systeem: 1 datum (in tabel 'afspraken'), en 'veel' (je weet niet hoeveel) mensen (userids) die willen komen (in tabel 'status' met velden afspraak_id en status). Zo'n dingen vereisen toch altijd x+1 queries, met x het aantal datums? : 1 voor alle (x) datums leeg te halen, en x voor per datum de status leeg te halen?

En ja, ik heb weinig ervaring met mysql

(beetje meer als basis)

zondag 2 juni 2002 17:46

Acties:

Hydra

Op zondag 02 juni 2002 15:04 schreef DiEana het volgende:
1 voor alle (x) datums leeg te halen, en x voor per datum de status leeg te halen?

Als het goed is niet.

SELECT u.naam, u.mail FROM cal AS c, user AS u WHERE c.user_id = u.ud AND c.datum = '1980-02-19';

Dit geeft de namen en e-mail adressen van alle gebruikers die op een bepaalde datum een afspraak hebben.

https://niels.nu

zondag 2 juni 2002 18:12

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 17:46 schreef Hydra het volgende:

[..]

Als het goed is niet.

SELECT u.naam, u.mail FROM cal AS c, user AS u WHERE c.user_id = u.ud AND c.datum = '1980-02-19';

Dit geeft de namen en e-mail adressen van alle gebruikers die op een bepaalde datum een afspraak hebben.

Ja, maar wat about: alle datums leeghalen en en per datum alle statussen ophalen. (een op veel?)

Dat kan volgens mij NIET in 1 query? Omdat je geen vast aantal kolommen hebt.

zondag 2 juni 2002 18:34

Acties:

ACM

Software Architect

Werkt hier

Op zondag 02 juni 2002 18:12 schreef DiEana het volgende:
Ja, maar wat about: alle datums leeghalen en en per datum alle statussen ophalen. (een op veel?)

Dat kan volgens mij NIET in 1 query? Omdat je geen vast aantal kolommen hebt.

Mja, ook al kan het met een query (als er 2 type acties nodig zijn, delete/update/select/insert whatever kan het sowieso al niet) wil dat nog steeds niet zeggen dat het dan ook sneller gaat

Ik kan een query maken die, ook al is het de meest efficiente (voor zover ik bedenken kan) query ergens voor.
De opsplitsing van die query om het per row te doen is alsnog sneller

Maar das dan ook wel een vrij enge left join enzo.

[edit]
Ik hoop trouwens voor je dat je het over een variabel aantal rijen hebt en das niet zo heel erg moeilijk met een database hoor

zondag 2 juni 2002 18:41

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 18:34 schreef ACM het volgende:

[..]

Mja, ook al kan het met een query (als er 2 type acties nodig zijn, delete/update/select/insert whatever kan het sowieso al niet) wil dat nog steeds niet zeggen dat het dan ook sneller gaat

Dat wou ik ook niet insinueren.. maar mijn "hoe minder queries hoe beter" werd een beetje te veralgemeend

Ik kan een query maken die, ook al is het de meest efficiente (voor zover ik bedenken kan) query ergens voor.
De opsplitsing van die query om het per row te doen is alsnog sneller

Dat wil ik best geloven, want ik heb het zelf al genoeg getest

[edit]
Ik hoop trouwens voor je dat je het over een variabel aantal rijen hebt en das niet zo heel erg moeilijk met een database hoor

Dat snap ik niet? Ik snap totaal niet wat je wilt zeggen?

zondag 2 juni 2002 19:26

Acties:

ACM

Software Architect

Werkt hier

Op zondag 02 juni 2002 14:27 schreef MrX het volgende:
Overigens heb ik het gevoel dat jij waarschijnlijk 90% van mijn gelul wel weet, maar hopelijk zijn er dan andere mensen die er iets aan hebben.

Anyway, enjoy

Ik had helemaal over deze reply heen gelezen

Ik weet inderdaad een groot deel ervan wel ja, maar voor de anderen is het natuurlijk altijd leuk

(voor mij natuurlijk ook wel)

Op zondag 02 juni 2002 18:41 schreef DiEana het volgende:
Dat snap ik niet? Ik snap totaal niet wat je wilt zeggen?

Als jouw query de ene keer meer rows (records?) teruggeeft dan de andere keer is er niets aan de hand.
Als dat resultset de ene keer echter 5 kolommen heeft en de andere keer 10 is er wel wat aan de hand.

Het eerste geval is inherent aan het principe van databases (en zeker bij 1 op n relaties, die n is niet voor niets 'variabel'

)
Het tweede wijst in veel gevallen op een slecht databasemodel, aangezien je er dan niet op kan rekenen dat je queries de ene keer een 'vergelijkbaar' resultaat geven als de keer erna??

zondag 2 juni 2002 19:53

Acties:

Verwijderd

Topicstarter

Op zondag 02 juni 2002 19:26 schreef ACM het volgende:

[..]

Ik had helemaal over deze reply heen gelezen
Ik weet inderdaad een groot deel ervan wel ja, maar voor de anderen is het natuurlijk altijd leuk
(voor mij natuurlijk ook wel)
[..]

Als jouw query de ene keer meer rows (records?) teruggeeft dan de andere keer is er niets aan de hand.
Als dat resultset de ene keer echter 5 kolommen heeft en de andere keer 10 is er wel wat aan de hand.

Het eerste geval is inherent aan het principe van databases (en zeker bij 1 op n relaties, die n is niet voor niets 'variabel' )
Het tweede wijst in veel gevallen op een slecht databasemodel, aangezien je er dan niet op kan rekenen dat je queries de ene keer een 'vergelijkbaar' resultaat geven als de keer erna??

Ha zo bedoel je.. dat bedoelde ik ook met de "1 op veel relatie"

En geval 2 is zeker niet.. het geval

Verstond je eerst niet () bedankt voor de toelichting

maandag 3 juni 2002 00:46

Acties:

Rense Klinkenberg

<xml />

Om een beetje globaler verder te gaan op het persitent bewaren van data met php, is het de moeite waard om eens te kijken naar VL-SRM: Vulcan Logic - Script Running Machine.

Het idee is dat er een aparte daemon draait waarin data kan worden opgeslagen vanuit een script. Aangezien de daemon niet als apache-child draait, kan je de data dus zeer goed persistent opslaan.

Aangezien het ook mogelijk is met een remote srm daemon te connecten, kan je het ook erg goed gebruiken in een server cluster.

Een andere handige feature is het concept bananas. Hiermee kan je de php code laten draaien op de daemon. Daardoor kan je dus eigenlijk de daemon uitbreiden met een bijna oneindige hoeveelhied mogelijkheden.

Helaas is het nog beta, maar het bied wel mooie perspectieven

Pagina: 1

Reageer