Fórum - Zobrazeno/Nezobrazeno.

Ikki:
Já bych to asi řešil takto: každý nový topic bude mít v databázi sloupeček videli, kam se budou zapisovat všichni, kteří ten příspěvek otevřeli (po otevření se zjistí, zda tam uživatel je, a pokud ne, zapíše se). Na hl. stránce se bude zjišťovat, zda je uživatel zapsán, a pokud ne, označí se jako nepřečtený.

Xanomes:
Jakého datového typu by takový sloupeček byl? Nechceš jednotlivé uživatele oddělovat čarkou, že ne?

Ikki:
Databáze umí rychle pracovat s množstvím dat o několik řádů vyšším, stovky či tisíce záznamů jsou nic. Jen prosím zauvažuj o lepším návrhu než tom, který píše výše Xanomes - tedy samostatné tabulce se dvěma sloupci.

Možná by šlo automaticky s topicem vytvořit soubor, kam při návštěvě zapíšeš <jméno uživatele> . ', ';. Aby tam uživatel nebyl 2x, tak to nejdřív přečteš přes fgetcsv($soubor, počet znaků);, což automaticky vytvoří pole, se kterým uděláš podmínku inarray($pole, <jméno uživatele>);, kterou taky budeš zjišťovat zda to uživatel viděl. 1500 uživatelů ale bude stále asi problém (1500 krát cca 10 znaků jména je 15 000 znaků, tedy cca 15kb), pokud nemají tví uzivatalé jednoznačně přidělené ID (v mysql), které bys zapisoval místo jména (ale těchto souborů by bylo stejný množství jako témat (tzn. pokud by jich bylo více než uživatelů, tak vytvořit tyto soubory uživatelům a zapisovat ID témat.)).

úsměv:
Doufám, že nechceš číst vždy celý soubor a upravit jej a znovu jej celý zapsat na disk?

A co, kdyby každý ten soubor byl setřízený? Pak by šlo v každém hledat v logaritmickém čase. Ale moment, to zase zpomalí přidávání nového uživatele do toho souboru. Ale slyšel, že něco o vyvážených vyhledávacích stomech, nešlo by do souboru uložit ten? Moment, tím jsem právě vytvořil to, co databáze zvládají posledních 20+ let.

Přestaň vymýšlet svá vlastní řešení, když existuje něco standardního, co skutečně funguje. Tvé rady jsou často neužitečné a ve výsledku mohou být i škodlivé - tvůj soubor se seznamem uživatelů bude ve výsledku pomalejší než databáze.

Ikki:
Vytvoř si tabulku videli (uzivatel, vlakno, cas). Při každé návštěvě updatneš čas. Při selectu vytáhneš uživatele pro vlákno, jejichž čas je větší než čas odeslání posledního příspěvku.
Pokud budeš mít správné indexy, tak toto zvládne miliony zhlédnutí; to v tvém případě budou měsíce návštěv uživatelů. Později můžeš zahazovat staré návštěvy a vlákno starší třeba než měsíc považovat za navštívené/nenavštívené, podle toho, co se ti bude víc hodit.

Juriad:
Já vidím jediný problém v tom že každé vlákno bude mít vlastní soubor. A ano, chci vždycky číst celý soubor (o jednom ultra dlouhém řádku). V připadě že to vadí... K ledu (s oběmi mými příspěvky tady).

Jinak: když si nový (jestli je nový se ověří přečtením jako csv a hledáním inarray) uživatel prohlídne vlákno, zapíše se jeho ID na konec souboru (fopen(/cesta, "a"). Když ve vlákně přibude příspěvek, otevře se soubor pro přepisování (fopen(/cesta, "w");) a zapíše_se('');. DB to zvládne taky, ale pro soubory je na hostingu většinou více místa.

PS (pro Juriad): I z osobních důvodů si tu dám pauzu. Naschledanou (nebo radči s Bohem?).

úsměv:
„DB to zvládne taky“
Ano, a mnohem lépe.

„ale pro soubory je na hostingu většinou více místa.“
To je spíš spekulace. A navíc Ikki pravděpodobně nenarazí na limit ani jednoho z nich.

Ikki:
Ano, dokázal bych to vyřešit. Rád pomáhám ale nerad dělám za někoho práci. A upřímně, nevypadá to, že by měl dostatek schopností to zvládnout jen s radami ale potřeboval bys někoho, kdo by to za tebe udělal.
Jinak mohu potvrdit to, co psal juriad. Stačí se starat o vazbu uživatel - topic, o kategoriích v tomto kontextu nemusíš přemýšlet, ty jsou totiž přece jednoznačně určené topicem.


„jak je tvořené toto fórum, tedy "textarea"“
Myslíš při editaci příspěvků? Tak ta automatická se dá udělat jednoduše tak, že víš, kolik máš řádků textu, tak podle toho nastavíš výšku textarea. Zde se to dělá pomocí inline stylu nastavujících ovýšku, já bych asi použil atribut rows. Úskalím jsou dlouhé řádky, které se v textarea zalomí. můžeš si ale zjistit, kolik znaků se průměrně vejde na řádek a dopočítat si, kolik tak asi dalších řádků bude potřeba.

„žádné zbytečné scripty přidávající mezi mezery <br />“

To zase bude tím, že se příspěvky do databáze ukládají tak, jak je uživatelé odešlou*. A nové řádky se na <br> převádějí až při výpisu. Toto je ten správný způsob. Špatný je ten, kdy se to převede ještě před uložením do databáze. Pak to přidělává problémy právě při editaci nebo při použití v jiném kontextu.

*nějaké úpravy probíhají ale jsou decentní a rozhodně negenerují html kód.

Ikki:
Ano, tyto záznamy tam budeš mít. Navíc bude primární klíč přes dvojici záznamů: uživatel, vlákno. A „update“ budeš provádět:
(Tento dotaz přidá záznam, pokud neexistuje, a pokud existuje, tak mu upraví čas.)

Neboj se množství záznamů, protože ty záznamy stejně někde stejně musí být uložené. Buď to budou ty soubory, jak úsměv navrhuje, nebo databáze, jak navrhuji já. Výhody databáze jsou:
* je to standardní řešení
* navržené na obrovská množství dat
* rychlé samo od sebe
* jednoduché použití
* umí toho mnohem víc, než teď potřebuješ

V případě PMek jsi vědět, že existují jen dva uživatelé, a proto jsi je mohl stav zprávy nacpat přímo do tabulky s PMkem. To ti u vláken nebude fungovat. Jak sám říkáš, budeš mít tisíce zhlédnutí.

Buď můžeš mít čas poslední odpovědi přímo v topicu, nebo každá odpověď zná svůj čas. Výhoda toho prvního je vyšší výkon, protože pro výpis vláken není treba JOIN na tabulku příspěvků.
Pokud to máš takto, stačí jediný JOIN na tabulku videli.


Pak výsledek bude obsahovat sloupec cas s časem poslední návštěvy, který snadno porovnáš s posledni_odpoved (nebo cas může být NULL, pokud vlákno ještě vůbec nenavštívil).
Ono by šlo přímo v dotazu zjistit, zda vlákno navštívil nebo ne, ale třeba se ti ta informace o čase může hodit i jinak: třeba v title odkazu na vlákno můžeš ten čas vypsat.