Rozwiązanie jest znane z IPB i wielu innych serwisów.

Osoba A wysyła prywatną wiadomość #1 do B.
Osoba B odpisuje na wiadomość #1 i widzi ją na tej samej podstronie (#2 pod #1).
Osoba A widzi wątek #1 jako NOWY. Wchodzi do środka. Tam widzi wiadomości - #1 (swoją) i #2 od osoby B.
I tak dalej...

W skrócie: wiadomości są wyświetlane jako wątki - jak na forum.

Dotychczas skrypt wyświetlał wiadomości osobno. Pola w bazie danych:

+ ID - ID wiadomości
+ topic - tytuł
+ owner - właściciel wiadomości, zazwyczaj odbiorca (ten, którego konto obciąża)
+ usr - odbiorca lub nadawca (w zależności od statusu)
+ st - status (1 - nowa, 2 - przeczytana, 3 - szkic, 4 - kopia)
+ date - data wysłania
+ txt - treść

W IPB prawdopodobnie istnieje dodatkowa tabela dla wątków. Ja próbuję zrobić to bez tworzenia dodatkowej tabeli. Założenie: jak najmniejsza ilość pól.

Dodałem nowe pole - th - numer wątku, czyli ID wiadomości nadrzędnej.

Warunek do listy wiadomości w folderze ODEBRANE (dla użytkownika o ID=1):

[SQL] pobierz, plaintext 
WHERE p.st<3 AND p.th=0 AND p.owner=1
[SQL] pobierz, plaintext 

Zakładam, że wiadomości nadrzędne mają wartość pola th równą 0.

Zapytanie wyświetlające konkretny wątek o ID=5 dla użytkownika o ID=1:

[SQL] pobierz, plaintext 
SELECT
	p.*, u.login, u.photo
FROM
	pms p
LEFT JOIN
	users u
ON
	p.usr = u.ID
WHERE
	p.owner=1 AND (p.ID=5 OR p.th=5)
ORDER BY
	p.th, p.date
[SQL] pobierz, plaintext 

Wszystko wyświetla się dobrze, ale przejdźmy teraz do wysyłania wiadomości:

Wg moich przemyśleń odbiorca musi otrzymać osobną kopię wiadomości. Może to jest błędne założenie?

Już tłumaczę, o co chodzi. Zarówno odbiorca i nadawca widzą całą swoją korespondencję - wiadomości wysłane i odebrane. Pewnego dnia jedna ze stron chce wyczyścić swoją skrzynkę. Mając tylko 1 kopię wiadomości, będzie to niemożliwe, gdyż wiadomości od niej straci druga osoba (a ona chciała sobie je zatrzymać dla siebie).

A więc nadawca przymusowo otrzymuje kopię listu, który wysłał. Wtedy do konfliktu nie dojdzie

Znacie inne, lepsze rozwiązania, aby zaoszczędzić miejsce?

Zaczynają się schody

Jak pamiętamy, wiadomości nadrzędne muszą mieć th=0.

Wiadomość #1 u osoby B ma inne ID niż u osoby A (bo to oddzielne kopie).

Osoba B chce odpisać osobie A. Tylko jest problem. Nie znamy ID wątku u użytkownika A. Gdybyśmy zapisali go w polu "th", osoba B nie zobaczyłaby wątku nadrzędnego na liście w folderze "Odebrane". A przecież odpowiedź ma pojawić się u A pod jego wiadomością, którą wysłał do B.

Jakie zatem proponujecie rozwiązanie tego problemu?

Mogę pokombinować z polem st (status) - tak, aby w polu th mógł znaleźć się ID wątku. Prostszym wyjściem jest stworzenie nowej kolumny w tabeli (też jest kilka opcji). Może służyć do połączenia z innymi wiadomościami lub określenia, czy jest nadrzędną wiadomością...

Jaka jest Wasza wizja?

PS. Czy w ten sposób nie złamię patentu na wyświetlanie wiadomości jako wątków? Czy dotyczy on tylko telefonów komórkowych i SMS-ów?

I to jest błąd. Dlaczego? Przy większym obciążeniu może dać nieźle popalić bazie. Problem taki sam, jak przy drzewkach, chyba że coś źle zrozumiałem.


Powiem to tak - lepiej zmarnować więcej miejsca, niż zbędnie komplikować strukturę: KISS

Nie, tu nie chodzi o drzewka, a dodatkowa tabela nic nie rozwiąże.

Chcę, aby powiązane ze sobą prywatne wiadomości były wyświetlane jak posty w wątku na forum - podobnie jak w nowym IPB. Bez dodatkowych poziomów zagnieżdżenia - po prostu w płaskim widoku. User A pisze do B, potem B odpisuje A (opcja Odpowiedz), z kolei A odpisuje B... Jednak wszystkie wiadomości są wyświetlane na 1 podstronie - czyli powstaje wątek.

Aby nie tworzyć 2 kopii tej samej wiadomości w tabeli, można stworzyć dodatkowe pole kto_usunal (DEFAULT 0).

Kiedy obie strony usuną wiadomość, zostanie fizyczne wydalona z bazy.

Aby wyświetlić wątek o ID=1 dla użytkownika UID=5, wystarczy warunek:

[SQL] pobierz, plaintext 
WHERE (p.owner = 5 OR p.usr = 5) AND (p.ID = 1 OR p.th = 1) AND p.kto_usunal != 5
[SQL] pobierz, plaintext 

Aby wyświetlić listę wiadomości, potrzeba:

[SQL] pobierz, plaintext 
WHERE p.st < 3 AND p.th = 0 AND p.kto_usunal != 5 AND (p.owner = 5 OR p.usr = 5)
[SQL] pobierz, plaintext 

Indeksy na polach: ID, th, owner, usr. Czy to jest dobre wyjście?

Co się bardziej opłaca? Tworzyć 2 kopie rekordów, czy współdzielić 1 kopię (jak powyżej)? Zależy mi głównie na wydajności.

Taki model nie sprawdzi się, gdy w dyskusji biorą 3 osoby lub więcej, ale z tym jest znacznie więcej roboty i nie wprowadzam.

Pierwsza wiadomość zostaje rodzicem wszystkich innych wysłanych z widoku wyświetlającą ją (tj. na stronie gdzie się wyświetla link typu "odpowiedz" przekazują parametr o rodzicu). Przy listowaniu wiadomości możesz stworzyć wątek po tej wartości. Zupełnie nowa wiadomość wysłana z innego miejsca nie ma rodzica i może stworzyć własny wątek jeżeli konwersacja będzie kontynuowana.