[php/mySql]Snelste oplossing?

[gitaarwerk]

Ik ben bezig momenteen met een community site aan het bouwen.. Nu zit ik aan wat dingen te denken...

Het is leuk als mensen je profiel bezoeken, dat je kan zien wie je heeft bezocht. Zo kom je een beetje in contact met andere gebruikers.

Het moeten de laatste 10 bezoekers op je profiel worden.

Enkele eigenschappen die ik wil gebruiken :
1. Username & ID
2. unix timestamp (om te kijken hoelang geleden de user is geweest)
3. (optioneel) de GenderNummer(man/vrouw). Deze kan ik ook eventueel ophalen, maar misshcien sneller is om mee te geven.

Nu zit ik te denken hoe ik dit het beste kan doen. In princiepe heb ik nog nooit met innerjoins gewerkt..maar ik moet even kijken (allene met ophalen uit meerdere tabellen..) Dit is een kwestie van even zelf uitzoeken.

Anyway,..
nu zit ik te bedenken.. ik verwacht binnen een jaar een bezoekeraantal van .. een paar duizend.. maar is moeilijk in te schatten.. mn doel is een hoop te kunnen plaatsen.

1)nu zit ik zelf aan het volgende te denken. In de user tabel 20 velden te plaatsen met het ID van de laatste 10 gebruikers.. en laatste 10 datelines.
Dit lijkt me wel een hoge load.
ik kan hier dan updaten bij het ophalen van de info en dan het record met limit 1 updaten gesorteerd op dateline. (alleen .. 10 dateline velden.. dan moet ik op 1 van die velden sorteren.... )

Lijkt me niet de meest snelste oplossing

2)Ik kan een koppeltabel maken met een timestamp erin..
Hier kan ik net als wat ik bij gastenboek heb gedaan.. eerst een count(*) array uitvoeren en daarna een verwijderen en een weer invoegen (of updaten als het er 10 zijn ipv inserten) alleen zit er weer een IF statement tussen.

Mij lijkt me de 2e manier het beste, maar beide nou niet echt snel.

Wat zijn jullie suggesties hierop?

[kvdveer]

Heb je benchmarks gedaan, dat je het niet snel noemt?
Als je een query als "SELECT iets FROM tabel left join andere tabel on user_id = user.id" te langzaam vindt, dan kun je beter van php/mysql afstappen - veel sneller kun je het niet krijgen zonder functionaliteitsverlies...

[djluc]

Sowieso: eerst normaliseren tot de 3e? normaalvorm? Daarna kan je eens gaan kijken of je misschien weer moet gaan denormaliseren. Waarschijnlijk is het nog niet eens nodig, sowieso kan je de resultaten ook cachen.

[gitaarwerk]

nee kvdveer.. ik "DENK" dat het te langzaam gaat zijn

@djluc.. ja..daar zat ik aan te denken..
misschien OF een recursieve query maken of weer een dubbel iets te gebruiken ..
alles is bij mij standaard zover mogelijk genormaliseerd. (normaliseren gaat me wel goed af had er een 10 voor (niet dat dat veel zegt ))

resulaten cachen heeft geen zin.. dit zijn namelijk gegevens die het meest veranderen..

Het beste lijkt mij (nu te zien) een koppeltabel met wat indexxen leggen en die in het opvragen van het profiel met een inner &/of left join opvragen. Het word sowieso een 1 op meer relatie. De gebruikersnamen moet ie weer opvragen uit de user tabel waar het profiel ook in staat.

[gorgi_19]

Ook een optie is om het gewoon er in et bouwen en als mensen gaan klagen over de load, de feature weer te disablen

[Verwijderd]

Extra velden in de profiel tabel lijkt me niet makkelijk om te maken, want hoe bepaal je welk veld overschreven moet worden? Dan moet je eerst de rij selecteren, in PHP het oudste veld bepalen en dan een query uitvoeren om dat veld te overschrijven.

Wat dacht je van:

• Een aparte tabel waarin je alle views opslaat
• De laatste 10 views ophalen doe je gewoon met SORT BY date DESC LIMIT 10

Nu heb je nog het probleem dat de tabel nogal bandeloos gaat groeien, dus:
• Eens per dag (nacht) prune je de lijst terug naar 10 per user dmv. een cronjob
• Of je doet de prune direct nadat je een nieuwe view aan de tabel hebt toegevoegd

Wat ook nog kan is 1 TEXT veld gebruiken in je profieltabel en daarin de laatste 10 hits in een (CRLF) delimited formaat opslaan. In PHP kun je dit veld dan redelijk eenvoudig als array manipuleren:

PHP:

function addHit($hitsfield, $uid, $datetime) {
  $hits = explode("\r\n", $hitsfield); // Uit elkaar halen
  array_unshift($hits, $uid . "|" . $datetime); // Element toevoegen (uid en date worden gescheiden dmv. | teken)
  $hits = array_slice($hits, 0, 10); // Beperken tot 10
  return implode("\r\n", $hits); // Veld teruggeven
}

Wat het snelste is... geen idee. Ik denk dat deze laatste ongeveer gelijk is qua tijd met de eerste (ophalen query / bewerken in php / bijwerken query), maar de logica erachter is eenvoudiger. Hoe deze het doen vergelijking met genormaliseerde queries, daar durf ik geen uitspraken over te doen. Daar zul je zelf wat testjes voor uit moeten voeren.

[ Voor 47% gewijzigd door Verwijderd op 10-01-2005 18:25 ]

[gitaarwerk]

@gorgi_19, lol.. is een mogelijkheid

@OneOfBorg,

Opzich is die array met een TEXT veld erg aantrekkelijk.. username en ID worden al uit een cookie gehaald (die goed beveiligd is wel). Die zou ik dus samen met ID en tijd en naam kunnen opslaan ja.. hoeft er ook geen 10 recursieve queies gedaan.

wat er nu gebeurt is een update query waar de user actief gezet word steeds. daarin zou ik hem kunnen opnemen.. (met een klein IFje)

het zijn beide wel aantrekkelijke oplossingen.

Ik heb momenteel al robots staan voor updaten
(Ik gebruik geen cronjobs, maar gewoon updates via timestamps.. die KAN ik aanroeken via cronjobs..of via speciale pagina's etc etc... maar daar heb ik nog geen plaatsing voor..de functionaliteit is in ieder geval aanwezig al! zal er wel mooi inpassen)

het lijkt me wel wat zwaar weer om veel te tellen. Als het goed is (komt) zijn er mensen dag en nacht aanwezig (ivm internationale users)

Ik ga het eens op een rijtje zetten en even kijken welke de minste queries vereist.

thanks!

[gitaarwerk]

*trap

ik heb er nog eens even over na zitten denken..

Ik heb de tabellen nu gemaakt.. en de simpele queries nog voor het normaal gebruik (site is nog niet actief..dus prune ze binnenkort wel)

nu zit ik te overwegen wat ik doe..ik wil niet dat iemand 10x in het profiel staat..dus moet ik updaten waar het ID al bestaat en dan daar de timestamp updaten.

Nu zit ik alleen even te kijken wat het snelste is.. ik wil geen extra query gebruiken om een check te doen. Ik dacht zelf om een update query te doen.. vindt ie de gebruiker dan niet..
dat ie dan in de or die() ipv mysql_error een insert query doet.

Is dat aan te raden om te doen? Mij lijkt me dat een mooie oplossing.

Ik doe in de scheduling functie wel prunen later (als er meer dan 10 laatste id's zijn).
of een GROUP BY gebruiken ..

Is zoveel inserts wel vriendelijk...vraag ik me af..

[ Voor 7% gewijzigd door gitaarwerk op 12-01-2005 10:18 ]

[gitaarwerk]

Ik krijg het toch nog niet helemaal voor elkaar hoor

code:

SELECT user.User_ID, user.User_Name, user.User_Gender, 
profile_visitors.Profile_Visitors_Dateline FROM profile_visitors, user WHERE 
profile_visitors.User_ID='$User_ID' AND profile_visitors.Profile_Visitors_User_ID= user.User_ID  
GROUP BY profile_visitors.Profile_Visitors_User_ID ORDER BY 
profile_visitors.Profile_Visitors_Dateline DESC LIMIT 10

Ik krijg netjes nu tien users enzo
alleen het probleem nu is dat hij sorteerd DESC op de hoogste timestamp(dateline) van de per group(users in dit geval)'s laagste timestamp...
dat laagte moet dus hoogste worden..
ik heb met MAX wat zitten kloten..maar kom er niet echt uit..