Autor Zpráva
Ikki
Profil
Zdravím přátelé,
potřeboval bych vytvořit nějaký zápis, který rozezná, zda-li uživatel daný topic viděl, nebo ne.
V podstatě.. Přidáme nový příspěvek do kategorie 1 a stav/obrázek se uživateli, který ten příspěvek ještě nemá přečtený změní na XX a když ho přečte/zobrazí, tak se XX změní na YY.

Děkuji za rady.
Xanomes_
Profil *
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ý.
Ikki
Profil
A není to příliš velká zátěž? V případě, že bude 1500 registrovaných, tak si myslím, že to bude velmi zátěžové.
anonym_
Profil *
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.
Ikki
Profil
anonym:
Bohužel sám aktuálně nevím, jak to vymyslet.
V případě PMek mi to tvořilo obrovský problém a taktéž aktuálně nevím, jak to u PMek dodělat, natož abych něco podobného dělal na fórum.
úsměv
Profil
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.)).
juriad
Profil
ú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.
Ikki
Profil
juriad:
Ikdyž vytvořím tabulku videli s daným obsahem, tak jak docílím toho, zda-li to uživatel viděl, nebo ne? V podstatě mám 20 kategorií a v každé je nový topic. Jak docílím toho, aby daný uživatel viděl, že v každé z těch kategorií byl připsán nový topic a když otevřel danou kategorii, tak aby mu to ukázalo, který topic je aktuálně nový a nepřečtený?
úsměv
Profil
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?).
Keeehi
Profil
ú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
Profil
Keeehi:
Byl by jsi alespoň ty schopný mi pomoci s tímto problémem? Opravdu nejsem schopný na nic přijít a Juriadova rada mi nepříjde příliš dobrá pro využití na fóru, nebo lépe řečeno nejsem schopný si nějak v hlavě představit, jak by se to mělo zapisovat pro každého uživatele, pro každou kategorii, pro každý topic/článek.

Taktéž bych se chtěl zeptat jednoho z administrátoru, jak je tvořené toto fórum, tedy "textarea", ve které se zobrazují odpovědi.
Je zde automatické rozšiřování, žádné zbytečné scripty přidávající mezi mezery <br />, které poté v textareii nefungují a je to velmi jednoduché a přehledné.
Keeehi
Profil
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
Profil
Keeehi:
Děkuji za pomoc. Vyřešil jsem to díky tvé radě a radě Davixe.
Aktuálně už mi pouze pozbývá to fórum.
V případě, že to udělám dle juriada, tak se vytvoří průměrně 100 řádků, které zaplní údaje typu:
Ikki, 3, 1267987
Ikki, 4, 1678958
Ikki, 5, 1756879, tedy jestli to chápu správně.

Nelze to udělat nějak tak, jak jsem to udělal s PMkami?
id, id1, predmet, uzivatel1, uzivatel2, zprava, cas, u1prec, u2prec.
V tomto případě funguje zápis jednoduše.
ID zprávy, ID odpovědí, -||-, odesilatel, prijimatel, -||-, -||-, odesilatel zprávu přečetl, příjemce zprávu přečetl.
Zápis do u1prec a u2prec je vypsán jako ano/ne.
V případě, že uživatel otevře danou zprávu, tak se zahájí příkat mysql_query(UPDATE #####), šlo by to i nějak takto? Bohužel si nedokáži představit, jak by to v tomto případě mělo fungovat.
Napadá mě pouze možnost u1prec = autor topicu, u2 = nick či id uživatele, který si daný příspěvek přečetl.

Já vím, že jsem opravdu hloupý, ale jakožto začátečník bych měl mít nějakou výmluvu, bohužel výmluva není řešení.
Děkuji Vám za trpělivost a odpověď, která mě povede k řešení.
juriad
Profil
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:
INSERT INTO videli (uzivatel, vlakno, cas) VALUES ('Ikki', 4, 1778973) ON DUPLICATE KEY UPDATE cas = VALUES(cas)
(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í.
Ikki
Profil
No dobrá, toto chápu.
Ale teď nastává moment, kdy nechápu další věc.
V případě, že "cas" bude vyšší, než timestamp, tak každý topic má nějaký jiný timestamp, takže jak nyní vytáhnout veškeré topicy a jejich timestamp a srovnat to s "cas" a daným uživatelem?
juriad
Profil
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.

SELECT v.*, w.cas
FROM vlakna v
LEFT JOIN videli w ON v.id = w.vlakno AND w.uzivatel = 'Ikki'
ORDER BY v.posledni_odpoved DESC

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.
Ikki
Profil
Dobrá, děkuji.
Myslím si, že jsem Vás již otravoval až příliš ohledně tohoto tématu, takže se pokusím to nějak vyřešit z Vaších rad a uvidíme.
Velmi si vážím vaší ochoty.

Přeji Vám pěkný den :)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: