Jak rozwiązać sprawę wiadomości w serwisie ?

Nie mam pomysłu jak rozwiązać pewną sprawę wiadomości. Chodzi o to że po wejściu w wiadomości po prawej stronie chciałbym mieć liste z kim pisałem a po wybraniu kogoś z listy z lewej jakby czat czyli co pisalem i co ktoś odpisał.
Zakładając że każdy user ma swoje ID zrobiłbym tabelkę
Conv_mapper

Ale jesli juz to jakos rozwiazemy to jak powinna wygladac tabelka z samymi wiadomosciami

no i nie mam pomyslu jak to rozwiązać ?

robisz tabelkę dość prostą jedna wystarczy

int id;
int sender; //id wysyłajacego
int recipient; // id odbiorcy
datetime datetime;//czas wysłania
text message; //treść

nic ci więcej do szczęścia nie potrzeba, teraz tylko odpowiednie zapytania które wcale nie są jakoś bardzo złożone. Tam się martwisz o podwajanie, nie powinno tak się stać, jeśli chodzi o rozmowę z jedną osobą to zwykłe WHERE (sender = myid AND recipment = yourid) OR (recipment = myid AND sender = yourid)

Edit. Co do listy z kim pisałeś zastosuj grupowanie

Tutaj racja i sortowac po dacie lub id to zachowamy chronoligczne dane. Ale z tym maperem to dobry pomysl ? zeby miec liste z kim pisalismy i zeby ktos mial tez liste z kim pisze ewentualnie ale te dwie tabelki nie sa ze soba polaczone zostaje tylko pobrane ID wlasne i ID odbiorcy

Nie rozumiem ciebie teraz. Wszystko co potrzebujesz, żeby zrobić to co opisałeś to ta jedna tabelka. Nie trzeba żadnej dodatkowej tworzyć.

Ale nie chce z jednej tabelki ciagnac i grupowac osoby ktore pisly. bobedzie coraz wiecej wpisow i wiecej to bez sensu by bylo chyba brac dane z takiej tabeli. wiec zrobie oddzielnie moze maper i tam bedzie info kto z kim pisze a dopiero potem wczytywanie wiadomosci z tej tabelki o ktorej pisales

Najsensowniejszą odpowiedź już uzyskałeś.

Ale owszem, możesz zrobić tabelę (id_odkogo, id_dokogo, id_wiadomosci), drugą tabelę wiadomosci (id_wiadomosci, tresc_wiadomosci), i nawet możesz zrobić trzecią tabelę rozmowy (id_rozmowy, id_wiadomości, nr_w_rozmowie).

Możesz też cudować dowolnie inaczej, tabelę od i do kogo podzielić na dwie, albo konfigurować to dowolnie inaczej.

Co ci przeszkadza ilość danych? Podam ci przykład tylko jednej tabelki z portalu który prowadzę 96360 rekordów, zajęte 5,4 MB i posiada zaledwie 10 kolumn ;) tyle danych się nazbierało po niecałych 7 miesiącach działania? Problem? Żaden. Jakbym miał tak rozbijać takie dane jak ty kombinujesz to zamiast 180 tabel bym miał jakieś 700 = utrata wydajności, poprzez masę JOINów i utrudnienie pracy przy kodowaniu.

Ja jeszcze nie jestem az tak zaawansowany :) ale dziekuje za pomoc. na razie zdecydowalem sie na te dwie tabelki.