Witam

Tworze swoj pierwszy projekt w php z wykorzystaniem mysql. W tej chwili rozgryzam jak najlatwiej informowac danego uzytkownika, ze od jego ostatniej wizyty w danym temacie lub artykule sa nowe, nie czytane komentarze/posty. Wpadlem na kilka pomyslow odnosnie "flagowania" w bazie np:

0 umieszczane w tabeli user w momencie wyslania nowego artykulu, i nastepnie w momencie jego wyswietlenia przez danego uzytkownika wyslanie "1" w to miejsce. Jednak to jest bezsensu.. Kazdy artykul czy temat to nowe kolumny.

Obecnie jestem na urlopie i pisze z telefonu, nie moge sobie testowac nic, jednak nie daje mi to spokoju, mysle nad rozwiazeniem juz od wczoraj, a php ucze sie dopiero od 2 miesiecy.

Robisz tabele łączącą Użytkownika z Artykułem.

Np tabela:

UserArticle:
user_id - klucz obcy na tabele User
article_id - klucz obcy na tabele Article

I reszte kolumn informacje jakie tylko chcesz zbierać.
count - ilosc odwiedzin danego artykulu
created - kiedy odwiedzil pierwszy raz
updated - kiedy odwiedzil ostatni raz
Co kolwiek tylko chcesz.

Jak nie ma wpisu dla danego uzytkownika i artykułu to po prostu artykul jest wlasnie dla niego nowy. Jak wyswietli dany artykul to wtedy tworzysz wpis.

A z autorskim forum? 300 wiadomosci i 50 uzytkownikow juz robi bajzel. Musze po ppwrocie przeanalizowac baze forum SMF, 59 user i 75 watkow.

Jaki bajzel? Jedna tabele ze stałą liczbą pól to dla Ciebie bajzel?

Jeden rekord dla kazdej wiadomosci i uzytkownika. Chce aby nowe komentarze byly oznaczane dla kazdego uzytkownika. Przy kilkuset komentarzach / wiadomosciach i kilkudziesieciu uzytkownikow daje to tysiace rekordow. Chyba ze zle kombinuje.

Tak, będzie to dawać tysiące rekordów - w czym problem?

Strzelam teraz trochę, ale czy nie możesz porównywać dat? Data przy każdej wiadomości i data wygaśnięcia sesji, no i później tylko dać "dziubka" jak w danym temacie data jest późniejsza? Tylko ze wtedy zostaje Ci przypadek jak ktoś się zaloguje i nic nie przeczyta czyli i tak musisz to gdzieś zapisać - tysiące rekordów ale za to kolumn tylko kilka : D

Wlasnie o datach takze myslalem i zamiast "tematy nie przeczytane" to bedzie po prostu "tenaty nie przeczytabe od ostatniej wizyty".

Z tymi rekordami w bazie to ok, ale co jak jest 2000 wiadomosci i 150 uzytkownikow - a to i tak male liczby. Rekordow moze juz byc miliony. Co praeda flagujemy tylko nowe, nie czytane tematy, jak uzytkownik przeczyta to mozemy to usunac calkowicie z bazy. A np. Dla uzytkownikow ktorzy nie logowali sie od miesiaca to calosc usunac.

I całość tych kolumn to wyłącznie liczby - a one nie zajmują dużo przestrzeni. Zawsze możesz zrobić tak, że np. komentarze starsze niż miesiąc już nie są oznaczane jako przeczytane/nieprzeczytane (domyślnie są przeczytane) i wtedy usuwasz niepotrzebne dane z tabeli.

Edit.
Według mnie większość użytkowników nie przeczyta tych komentarzy - dlatego lepiej dodać wpis tylko dla przeczytanych np. z ostatniego miesiąca. Cała reszta jest nieprzeczytana, a te starsze niż miesiąc są domyślnie przeczytane.

Zastanawiam się jak ze strony technicznej to zrobić.. wyświetlenie tematu dodaje wartość do tabeli `mark_read` gdzie są pola: user_id oraz temat_id.

Każdy nowy post usuwa wszelkie wartości z tabeli `mark_read` gdzie temat_id = aktualny temat_id.

Każdy nowy użytkownik będzie sprawdzany czy NIE istnieją wartości z jego id w polu user_id w tabeli `mark_read` - jeżeli prawda - brak nowych postów, jeżeli nie to odpowiednia ikonka na forum.


Jak dla mnie to strasznie dużo zapytań do bazy, co prawda nie mam dużej strony, bazy użytkowników przewiduje na 40-50 maksymalnie. Dziennie unikalnych wejść obecnie stat4u pokazuje 10-20, najwięcej 39 - więc szału nie ma (małą strona klanowa) jednak mimo to, bez systemu cache wydaje mi się to wszystko ciężkie.

Dodaj do tabeli mark_read pola "data_przeczytania" (ustawiane na czas bieżący przy dodawaniu/aktualizacji wiersza) i ew. "post_id" (id ostatniego posta w wątku, który użytkownik miał szansę przeczytać).
Z takiej tabeli nie usuwaj wierszy przy każdym dodaniu posta. Usuwaj je cyklicznie codziennie (albo co miesiąc) dla wpisów o "data_przeczytania" starszym niż 30 dni (zapobiegnie to puchnięciu tabeli, którego się boisz), a jednocześnie uznawaj, że jeśli ostatni post w danym wątku został napisany wcześniej niż 30 dni temu, to każdy użytkownik ma ten temat oznaczony jako przeczytany.
Temat oznaczasz jako nieprzeczytany tylko wtedy, gdy istnieje wpis w "mark_read" o "data_przeczytania" mniejszym niż data dodania ostatniego posta (warto rozszerzyć o taką kolumnę tabelę "tematy", żeby nie obliczać na żywo).

Kolumna "post_id" może posłużyć do wyróżnienia postów napisanych od ostatniej wizyty w wątku, przy czym w przypadku braku wpisu w mark_read takimi postami będą wszystkie posty napisane w ciągu ostatnich 30 dni.

Żeby jeszcze bardziej sobie uprościć życie, proponuję napisanie takiego widoku w bazie danych:

[SQL] pobierz, plaintext 
CREATE OR REPLACE VIEW tematy_uzytkownicy AS
SELECT 
    t.*,
    u.id AS user_id,
    CASE
        WHEN t.data_ostatniego_posta < DATE_SUB(CURDATE(), INTERVAL 30 DAY) THEN 1 -- jesli ostatni post napisano 30 dni temu lub wczesniej - temat przeczytany
        WHEN mr.temat_id IS NULL THEN 0 -- w przeciwnym razie jesli nie ma wpisu w mark_read - temat nieprzeczytany
        WHEN mr.data_przeczytania < t.data_ostatniego_posta THEN 0 -- lub jesli jest wpis, ale data przeczytania jest starsza niz data dodania ostatniego posta - temat nieprzeczytany
        ELSE 1 -- w przeciwnym razie przeczytany
    END AS czy_przeczytany
FROM tematy t JOIN uzytkownicy u LEFT JOIN mark_read mr ON (mr.temat_id = t.id AND mr.user_id = u.id)
[SQL] pobierz, plaintext 

Potem odpytujesz widok np. takim zapytaniem:

[PHP] pobierz, plaintext 
$sql = "SELECT * FROM tematy_uzytkownicy WHERE user_id = '$user_id'";
[PHP] pobierz, plaintext 

I otrzymujesz wszystkie tematy z punktu widzenia tego użytkownika, a w kolumnie "czy_przeczytany" masz zero-jedynkową informację o tym czy dany użytkownik przeczytał temat czy nie (i czy nie należy go np. pogrubić na liście).