Chcialbym umiescic na stronie system wymiany wiadomosci pomiedzy uzytkownikami. Przychodzi mi do glowy wiele rozwiazan co do struktury tabel bazy dnaych. Nie posiadam jednak odpowiedniego doswiadczenia zeby zaplanowac optymalna strukture tabel. Do tej pory przeprowadzalem na bazach proste operacje.Czas mi nie pozwala na analizowanie gotowcow zeby wychwycic w nich sposob w jaki te operacaje sa przeprowadzane. Pisze wiec tutaj moze ktos z was mial juz z tym stycznosc i prosil bym o ile to mozliwe o rzeczowe objasnienie co do tego jak gdze i w jaki sposob maja byc przechowywane ow wiadomosci i w jaki sposob powinny byc one kojarzone z uzytkownikami.

Za pomoc i zainteresowanie z gory dzekuje i pozdrawiam...

Tabela messages.


Nie za bardzo widzę w czym trudność.

Masz pełną dowolność. Możesz dodać flagi czy wiadomość jest w koszu, czy została przekazana, czy została na nia wysłana odpowiedź, ...

Czyli sugerujesz oddzelna tabele pod wiadomosci? Wlsciwie to byla pierwsza mysl jaka mi rzyszal do glowy ale przy glebszej analizie pojawily sie watpliwoasci pewnie na wyrost ale jednak...

A jest jakaś inna sensowna możliwość?
Oddzielna tabela to jedyne rozwiązanie jakie wchodzi w grę.

Jakie?

Indywidualna tablica dla kazdego uzytkownika Autor trzyma wiadomosc no i kwestia delete nie jest jeszcze dla mnie calkim jesna

Wiadomosc musi byc przechowywana do momentu odczytanie i wtedy jakies kosmosy zeby zbadac czy autor lub tez odbiorca nie chce jej przechowywac przy indywidualnych tablicach wiadomosc ktora zechcial by przechowac Obiorac bedze nadal u Nadawcy no sam juz nie wiem no i nie sprawdzalem czasu dostwpu przy jednej mega tabilcy i przy indywidualnych bo jesli to autor ma przechowywac wiadomosc to u odbiorcy powinna sie znalesc jeszcze inna tablica z id nadawcy wiec dwie indywidualne tablice dla kazdego uzytkownika jedna z nadawanymi wiadomosciami a druga z odbiranymi

A dlaczego chcesz tworzyć tabelę dla każdego użytkownika Tak jak mike_mech podał ... jedna tabela masz tam id_nadawcy i id_odbiorcy.

Nic więcej do szczęścia nie potrzeba.

No wiec oka nie bede przepychal dalej tego pomyslu. Bedze jedna tablica nie ma co komplikowac zwlaszcza ze nie mam zadnej pewnosci ze tak bylo by szybciej i obnizyl bym bezpieczenstwo aplikacji bo wchodzlo by w gre create i drop pozdrawiam...

Dobrym sposobem na "elastyczne zarządzanie" użytkownikami w tym przypadku to zrobienie tej struktury na dwóch tabelach. W jednej użytkownicy: ID | Nazwa | (Inne jak np Nazwisko etc) a druga to posty ze wszelkimi polami jakie ci są potrzebne (PostID | FROM | TO | Date | Temat (etc)) - i złączenie obu poprzez klucz obcy w tabeli postów - czy wolisz do kolumny FROM czy TO - to generalnie obojętne - drugą kolumnę możesz zawsze dopiąć kodem.

Pzdr