Keskustelu: Nettisivujen teko: Linkkien järjestely suosituimman mukaan

Morjens!

Tarvitsen apua siihen kuuluisaan "out-of-the-box"-ajatteluun..

Eli sivuillani kävijät voivat linkittää omia sivujaan linkki listaan ja aina kun linkkiä klikataan niin tietenkin kävijä ohjataan sille sivulle samalla lisäten tietokantaan tämän klikkauksen.

Tarkoitus olisi saada linkit järjestymään suosituimman mukaan klikkauksen perusteella. Tietenkään tämä ei ole ongelma mutta jos on seuraavanlainen oletettu tilanne:

Linkkejä on lisäilty jo jonkin aikaa ja suosituimpaan linkkiin on tullut klikkauksia jo vaikkapa miljoona. Sitten eräänä päivänä Pekka Perus lisää linkin sivuilleen josta tuleekin supersuosittu. Tämän linkin nousu ykköseksi kestää kuitenkin verrattain kauan koska muut linkin on ollut klikkauksien kohteena paljon kauemmin.

Eli onko kenelläkään ideoita miten tämmöisen voisi hoitaa että Pekan linkki nousee listan kärkeen kuten supersuositun sivuston kuuluukin?

-t0ll0

edit: Tuli mieleen että tietenkin kun lisätään timestamppi linkin lisäyksestä niin lasketaan päivät siitä päivämäärästä tähän päivään ja jaetaan klikkauksien määrällä?

No, jos laitat vaikka lisäyshetken sinne ja sitten jaat klikkausten määrän sillä, kuinka monta sekuntia (nykyhetki miinus lisäyshetki) linkki on ollut järjestelmässä. Sitten sorttaat ne näin saadun "klikkauksia per sekunti" perusteella.

Sitten voi tietty ajatella että se miljoona latausta saanut sivu oli kiinnostava silloin vuosi sitten. Edellisen lisäksi voisi miettiä, että ottaisi huomioon klikkausten määrän esim. vain viimeiseltä kuukaudelta.

vuoden/kuukauden/viikon/päivän -klikatuin linkki. Nämä mahdollistavat sitten nousun kaikkien aikojen -klikatuin linkki listalla nousemisen.

Grez. juurikin tuli sama mieleen ja pistin edittiä :)

En tiedä onko tarpeen sekunnin tarkkuudella saada vaan riittänee klikkaukset per päivä. Vai aiheuttaako tämä vain turhaa laskemista palvelimelle jos aletaan vielä muuttelemaan päiviksi sekunnit?

Sekunteista on selkeästi helpompi laskea, jolloin ajan pyöristämisestä ei tule ongelmia. Muutenkin, kun tietokanta sekunteja tukee, niin ehdottomasti sillä.

Muutenkin "virhemarginaali" pienenee sekunteissa nopeammin, jolloin jo päivän ollutta linkkiä ei yksittäiset klikkailut pompauttele hysteerisesti, ihan näin testaamatta ajatellessa.

Lebe80 varmisti tän asian!

Selkis eli cps, clicks per second, mennään.

Nyt testailujen jälkeen voinkin todeta että fiksumpi tapa voi sittenkin olla "cliks per day".
Sekunteilla homma menee helkutin pitkälle desimaalien puolelle.

Ellei sitten laskutoimituksessani ole jotain vikaa?

$cps = $clicked / (time() - strtotime($timestamp));

Eli clicked = montako kertaa linkkiä on painettu ja timestamp milloinka linkki on lisätty.

Mutta kyllähän se järjelläkin ajateltuna että jos viikossa on sekunteja 604800 ja klikkauksia viikon aikana vaikkapa 386 niin aika tarkkoihin lukemiinhan ne menee.
eli decimal(10,10) :)

edit:
elikkä tähän tyyliin:

$cps = $clicked / ((time() - strtotime($timestamp)) / 86400);

Toisaalta jos käytät floatia, niin ei ole mitään väliä mikä miinusluku siellä eksponentissa on.

Päivätkin on toki ihan hyvä, mutta kannattaa laittaa sitten myös desimaaliosa mukaan.

Sitten yksi vaihtoehto on laittaa spc eli sekunteja per klikkaus.

Think outside the box: on parempi idea suorittaa tuo lasku suoraan SQL-kyselyssä. Esimerkissä sarake 'url' sisältää osoitteet, 'clicks' klikkausten määrän ja 'added' lisäyspäivän date-muotoisena arvona. Huomaa, että tulokset saadaan myös valmiiksi suosituimmuusjärjestyksessä.

SELECT url, clicks * 86400 / (UNIX_TIMESTAMP() - UNIX_TIMESTAMP(added)) AS cpd FROM links ORDER BY cpd DESC;

Minusta sen laskun suorittaminen jossain muualla kuin kyselyssä Order By yhteydessä olisi nimenomaan normaalista poikkeavaa, eli ikäänkuin "thinking out of the box".

En näköjään edes kiinnittänyt huomiota siihen että t0ll0 niitä tosiaan laskeskeli PHP:llä.

Grez kirjoitti:

Minusta sen laskun suorittaminen jossain muualla kuin kyselyssä Order By yhteydessä olisi nimenomaan normaalista poikkeavaa, eli ikäänkuin "thinking out of the box".

Näinhän se periaatteessa on. Harrastelijoista suuri osa vaan tuntuu olevan 'PHP-koodareita' eikä 'web-kehittäjiä' (no offense), ja he näkevät tietokannan vain tietovarastona, joten sitä ei osata hyödyntää täysimittaisesti.

Eihän 'think outside the boxkaan' (out of the box tarkoittaa ihan jotain muuta) meinaa vaihtoehtoisia tapoja tehdä asiat huonommin, vaan juuri totutuista tavoista irtaantumista ja uusien, tehokkaampien metodien löytämistä.

Ikään kuin tämä minusta parempaa koodaria tekisi mutta omaksi puolustukseni: Suoritan tuon laskutoimituksen kerran päivässä ja pidän clicks per day tulokset omassa sarakkeessaan.
Ajattelin että homma olisi parempi tehdä näin ettei joka sivulataus kerralla laskeskella ja sen perusteella järjestetä.
Ei sivuni kuitenkaan niin suosittu ole ettei päivittäinen listan järjestyksen päivittäminen riittäisi!

Mutta tuosta sain kyllä idean ja jäin pohtimaan että miksen sitten pistä updateen noita laskutoimituksia...

edit:
mutta eipä tämä niin helppoa olekkaan.. ainakaan minulle
mikähän seuraavassa mättää?

mysql_query("UPDATE taulu SET cps = '(clicked * 86400 / (UNIX_TIMESTAMP() - UNIX_TIMESTAMP(timestamp)))' WHERE...

Vai oonkohan mä ny ihan hakoteilla.. takasin oppaiden ääreen.

edit2: jospa avais silmät vaiheeks.. kiitoksia kaikille vastanneille! nyt toimii näppärän nopsasti

Eihän sitä ajonaikaisesti pitäisikään laskea, jos sinulla on satoja tuhansia linkkejä ja useita yht'aikaisia sivulatauksia. En vain usko, että tämä on todellinen tilanne, joten pääsisit vähemmällä vaivalla, kun pidät asiat yksinkertaisina.

Hakemasi update-lauseke menisi seuraavanlaisesti:

UPDATE taulu SET cpd = clicks * 86400 / (UNIX_TIMESTAMP() - UNIX_TIMESTAMP(added));

The Alchemist kirjoitti:

Eihän sitä ajonaikaisesti pitäisikään laskea, jos sinulla on satoja tuhansia linkkejä ja useita yht'aikaisia sivulatauksia.

Jos todella on suoraan sarake clicked ja sarake added, yksi pieni lasku kyselyssä tuskin tuntuu missään. Jos klikkaukset tallennettaisiin yksitellen johonkin toiseen tauluun (esim. yhdessä klikkaajan tunnistetietojen kanssa), voisi tulla ongelmia.