Nepřečtené příspěvky ve fóru – PHP – Fórum – Programujte.com

Jak nejlépe řešit tento problém pro všechny uživatele na webu? Napadlo mě si pro každou diskusi uložit pro daného uživatele tabulku, ale diskuse přibívají i uživatelé. Takže přidávat tabulky. Ale pokavaď uživatelů bude např. 1000, diskusí taky, je to 1000x1000 tabulek a to už může být db trošičku zpomalená. Jak byste tento problém řešili vy?

A co tak si nadefinovat v css jinou barvu pro prectene odkazy?? ;)

O tohle mi nejde, jak to zobrazit. Jde o to, jak u každého uživatele ukázat co on má nepřečtený.

Můžu udělat např. sloupeček stav, kde bude např. hodnota 0, 1, přečtený, nepřečtený. Ale když přijde jeden uživatel, klikne na to a nastaví se to na přečteno :) a u druhého bude taky přečteno, ikdyž on o tom nemá tušáka.. Si mě nepochopil, jak sem to myslel.

To wise : Musíš udělat speciálně pro toto tabulku, kde budeš zaznamenávat u každého přihlášeného uživatele, zda-li dané vlákno / příspěvky (případně kolik) přečetl.

Tabulka by mohla vypadat takto:
id ctenar frumid frum_vl frum_pst datum

ID - auto increment ID
ctenar - ID ctenáře
frumid - ID diskuze (PHP...)
frum_vl - ID vlákna (Jak instalovat Apache...)
frum_pst - počet příspěvků, když to naposledy navštívil (5...)
datum - datum posl. návštěvy (DATE-TIME, doplňující, nepovinné)

Při každé návštěvě vlákna (tedy při čtení příspěvků) se aktualizuje na konci (tj. po vypsání příspěvků, na konci skriptu) počet příspěvků (frum_pst), díky počtu zjistíš, kolik nových je od posl. návštěvy (rozdíl počet příspěvků ve vláknu a počet ve frum_pst), stejně tak zjistíš, zda-li toto vlákno už navštívil (bude v DB existovat záznam pro daného uživatele a dané vlákno).

To Curo : Jen tak pro zajímavost, kolik mb má aktuální tabulka na prog?

a mna by zaujimal cas spracovania v ms pri jednej kontrole jedneho prispevku.... :) ak budes taky dobry...

takze test:

tabulka:

CREATE TABLE `prectene` (

  `user` bigint(20) NOT NULL,

  `forum` bigint(20) NOT NULL,

  `ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

  UNIQUE KEY `user_2` (`user`,`forum`),

  KEY `ts` (`ts`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

use DBI;



$db = DBI->connect('DBI:mysql:test:localhost','login','heslo');

$i = 0;

while ( $i++ < 400 ) { 

  $j=0;

  while ( $j++ < 10000 ) {

    $db->do('insert delayed into prectene (user,forum) values ("'.$i.'","'.$j.'")');

  }

  print $i,' ',$j,"\n";

}

use DBI;

use Time::HiRes qw(gettimeofday tv_interval);



$db = DBI->connect('DBI:mysql:test:localhost','login','heslo');

$x = $db->prepare('SELECT ts FROM prectene WHERE user = ? and forum = ?');





$i = 0; $cnt = 0;



$t0 = [gettimeofday];

while ( $i++ < 100000 ) {

  $x->execute(int(rand()*500),int(rand()*10000));

  if ( ($ts) = $x->fetchrow ) {

    $cnt++;

  }

}

$elapsed = tv_interval ( $t0, [gettimeofday]);



print "$cnt $elapsed\n";

To KIIV : necakal by som tak dramaticky rozdiel bez a s indexami (ja som skusal nieco podobne pred nedavnom a nemal som az taky rozdiel).. dakujem za nazornu ukazku...

To marioff : tak kdyz je tam par stovek zaznamu tak to bez indexu jeste vladne...
ale kdyz uz je to 240MB soubor (z toho skoro tretina index :D) o 4 milionech radku tak uz je to zatracenej rozdil...
precijen bud projde vse nebo nic... mozna by to bylo jeste zajimavy dat s limit 1 ale to uz je jedno sem to zase promazl...
kazdopadne toto neni zase nejakej extremni procesor... obyc core duo pro notebook :)

To marioff : Díky indexům je to nepatrné při čtení vlákna (tedy příspěvků), nebo diskuze.
Nejhorší je to na HP fóra, kdy se to musí nasčítat.

Samozřejmě, dobré je cachovat, ale to je zase o něčem jiném, odpovídal jsem pouze na to, jak by mohla vypadat TAB pro přečtené.

To KIIV : Ty jsi testoval jen při uchovávání ID diskuze (asi, forum === ID diskuze předpokládám), pro lepší select a šetření výkonu je dobré uchovávat jak ID diskuze, tak vláken a samotných příspěvků (počet).

To Curo : no samo je to jen navrzeny trosku naivne.. tj ze si uchovam jen cas precteni a pak by se spocetlo kolik veci s novejsim casem je v tom vlaknu...
taky je to jen test na rychlost vyhledavani nad jednoduchou tabulkou...
jeste by tam bylo potreba to spocteni .. tj asi vytahnout nazvy a id vlaken, dalsim dotazem pak spojit prectene s prispevky a count(*) kdyz bude prispevek novejsi... pri otevreni vlakna pak update konkretniho klice uzivatel a forum (vlakno)

pocet prispevku neni spatnej napad, akorat jak delas, kdyz nekdo svuj prispevek smaze? update prectene set pocet = pocet-1 where forum = ... ?

Díky za názory, jenom pro doplnění.
To Curo : uživatel zjistí, zda-li jsou ve vláknu nové příspěvky až po přečtení vlákna, resp. při jeho otevření. Takže to chce udělat už v diskusi pro všechna vlákna. Ale to už je detail. Každopádně díky za pomoc, nějak takto jsem si to představoval, ale pořád mi to nedocházelo.

To KIIV : pěkná ukázka. trošku divočejší rozdíl :)

To Curo : tento navrh je trošku špatne, jak už tu lehce zanělo, je lepší ukládat např. čas posledního přečtení vlákna, nebo lépe ještě id posledního připraveného příspěvku. pač kdybych ukládal jen počet, pak někdo smaže jeden post a hle... :)

To hrach : jak to myslíš připraveného?

To wise : omlouvám se, myslel sem přidaného :) na co to myslím?

to nevim a radši nechci vědět :o) každopádně všem díky pánové za recepty :) určitě něco uvařím

To KIIV,hrach: ukládat ČAS u fóra a dle toho počítat (zobrazovat) nové příspěvky je brutální řešení, nepoužívat. To je právě to, čemu je třeba se vyhnout a to hned v základu.

Proto je potřeba počítat počet příspěvků. Ano, pokud někdo smaže svůj příspěvek, přepočítá se počet příspěvků, případně to přepočítá skript pouštěný BOTem (eventuelně CRONem).

To wise:

uživatel zjistí, zda-li jsou ve vláknu nové příspěvky až po přečtení vlákna, resp. při jeho otevření. Takže to chce udělat už v diskusi pro všechna vlákna.

Když už jsme u tohoto tématu mohl by mi někdo poradit co mám na níže uvedeném kodu špatně

$diskuse=mysql_query("SELECT cat.nazev as tema,dp.reakce as reakce,dp.id as id,

us.nick as autor,us.jmeno as jmeno,prispevek,

DATE_FORMAT(datum,'%d.%m.%Y %H:%i:%s') as date 

FROM prispevky as dp,

users as us,

category as cat 

where (dp.id_autora=us.id and 

cat.id=dp.id_diskuse and dp.id_diskuse='$tema')

 $nove group by dp.id order by dp.datum DESC ") or die (mysql_error());

if($_GET['zobrazit']=='nove') 

{

$nove="and dp.datum>us.lastlogin";



}

To Paja2 : a co vypsat nejaky hodnoty? treba ten last_login - treba si ho prepises nejakou prilis novou hodnotou (aktualni cas ci podobne a pak by musela byt uz docela haluz aby si neco ziskal), taky co ti to vypisuje bez te casove podminky?

To KIIV : Bez časové podmínky se vypíší všechny příspěvky, s časovou podmínkou jen nové příspěvky, které uživatel nepřečetl

to, co ted napisu, je kompletne z hlavy, bez testovani, zkusenosti, atp. ale teoreticky by to melo fungovat:
1 dotaz na 30 vlaken vcetne neprectenych postu v nich ...

select vlakna.*, count(posty.id) from vlakna

left join precteno on precteno.vlakno_id = vlakna.id and precteno.user_id = XXX

left join posty on posty.vlakno_id =  vlakna.id and posty.posted_dt > precteno.dt

where vlakna.topic_id = XXX

group vlakna.id

limit 1, 30

To Paja2 : si napsal ze to nic nevypise ... pokud to funguje muzes ten test co sem zminoval klidne zapomenout

a co tak na to skusit pouzit COOKIE? kazda tema sa oznaci ako neprecitana a potom cez podmienku ak bude zalozene cookies v uzivatelskom PC o tom ze to precital tak sa mu zobrazi iny obrazok... mohlo by to fungovat.. cize napr.

if(!isset($_COOKIE['precitane_".$idtemy[0]."'])) {

echo "<img src='images/neprecitane.png' alt='Neprecitane' title='Neprecitane' />";

}else{

echo "<img src='images/precitane.png' alt='Precitane' title='Precitane' />";

}

nene, cookie ne; za prvne lidi migruji mezi pc, za druhe rozhodne ne pro kazde vlakno jednu cookie, za treti i ta cookie se muze ztratit- uzivatele cas od casu maji ve zvyku si sve cookie smazat - minimalne ja.

hrach napsal:
nene, cookie ne; za prvne lidi migruji mezi pc, za druhe rozhodne ne pro kazde vlakno jednu cookie, za treti i ta cookie se muze ztratit- uzivatele cas od casu maji ve zvyku si sve cookie smazat - minimalne ja.