witam

chciałbym poznać Wasz sposób na system komunikacji użytkowników w serwisach społecznościowych.

co jest potrzebne:
- wysyłanie, odbieranie poczty
- możliwość usuwania poczty, przenoszenia do kosza
- możliwość przeglądania poczty odebranej, wysłanej i tej w koszu

w zasadzie to tyle 'kłopotliwych' kwestii.
ja zrobiłem tabele poczta i pogubiłem się podczas programowania. czy nie prościej byłoby zrobić 2 tabele: odebrane i wysłane?

podzielcie się swoimi rozwiązaniami.

pozdrawiam

a nie prosciej dac pole okreslajace czy wiadomosc jest w inbox, sent czy trash?

no prosciej, ale prosze o bardziej wyczerpujaca odpowiedz:)
mam kolumne kosz, mam kolumne przeczytane.
ale przeciez u nadawcy moze byc ona w koszu a u odbiorcy juz nie koniecznie:)
a to przeciez ten sam wiersz jest.
wiec musza byc 2 kolumny z typem wiadomosci - tzn z miejscem skladowania.
ale musi tez byc mozliwosc calkowitego usuniecia - nawet z kosza.
jak odbiorca usunie ta wiadomosc na stale to u nadawcy nie koniecznie musi byc ona usunieta:)

wiec dlatego pomyslalem o dwoch tabelach - tak jak jest w normalnej poczcie.
odbiorca i nadawca ma ja na serwerze, lub sobie ja usuwa nie wplywajac na konto pocztowe drugiej strony.

Ja bym zrobił to tak

troche nie rozumiem tego twojego zapisu.
dodam ze pisze aplikacje na symfony - pierwszy raz mam do czynienia z tym FW i dla mnie to jest bardzo zamieszane.

bo zalozmy sytuacje ze jest 1 tabela no i kolumny z ID odbiorcy nadawcy, jakies flagi czy przeczytane, w ktorym folderze u kogo sie znajduje (folder_odbiorcy, folder_nadawcy) no i user przeglada tylko te z kosza. w koszu sa chyba listy odebrane i wyslane. wiec trzeba zrobic joina do profilu nadawcy i do profilu odbiorcy.

takze to tez jest warunek - zeby mozna bylo prosto napisac aplikacje w symfony:)

Moje rozwiązanie może Ci nie pasować - owszem. Wyjaśnię tylko, dlaczego możliwość usuwania wysłania wiadomości jest rzeczą zbędną. Ja uważam, że to użytkownik otrzymujący wiadomość powinien mieć pełne uprawnienia. Gdy "usunie do Trash" wiadomość, jej status zmieni się na deleted. Gdy usunie ją z Trasha, zmieni się na hidden. Fizycznie wiadomości nie usuwamy, bo musi pozostać ona w "Sent" naszego użytkownika-nadawcy.

Widzę, że próbujesz na siłę zaimplementować funkcjonalność SMTP/IMAP w prostą (z założenia potrzeb) aplikację prywatnych wiadomości. Jeśli o to Ci chodzi, to może z automatu zakładaj skrzynki mailowe z virtuaboxami na sql, stwórz webmaila i ogranicz możliwość wysyłania i odbierania wiadomości do adresatów z Twojej domeny. I voila Będzie to o tyle lepsze rozwiązanie niż tradycyjne PW, że delikwent będzie mógł pobrać wiadomości (zostawiając kopię - ustawienia serwera, nie klienta) na komputer korzystając z np. Outlooka i przeglądać je nawet gdy serwis będzie offline. Oczywiście prosto z Outlooka będzie mógł odpisać lub napisać nową wiadomość Czyli taki "intramail" globalnie

ale czy konieczne jest trzymanie zbednych wiadomosci? jak obydwie strony ja usuna to po co mi ona ma miejsce w bazie zajmowac?
ale czy dobrze rozumuje z tymi dwoma kolumnami?
bo jak nadawca zmieni status deleted to nie koniecznie musi oznaczac ze odbiorca tez ma ja miec w koszu.
wiec chyba to jest jedyna droga?



tez o takim czyms myslalem. ale z drugiej strony informacja na maila o nowej poczcie jest motywacja zeby wejsc na strone i przy okazji cos tam poogladac, kliknac reklame:)

takze to bym zrobil w ramach pracy dyplomowej ale juz magisterskiej:) jak zdaze oczywiscie.

Akurat teraz pisałem prywatne wiadomości i ja zrobiłem to na jednej tabeli. Tabela wygląda w skrócie tak:

I w katalogu wysłane, sprawdzam po prostu nie od kogo jest wiadomość a do kogo Tak naprawdę cały mechanizm to pobranie danych, przenoszenie i kasowanie wiadomości + kilka ifów żeby w folderze wysłane nie wyświetlało się "Od" tylko "Do"

daj linka do testow:) bo cos za latwo to opisujesz.

A nie można po prostu

id | sender | receiver | ... | status_sender | status_receiver

To jest chyba najprostsze rozwiązanie. Wysyłający i otrzymujący mają osobną kolumnę na status (kolumny typu ENUM). I tyle.

Takie rzeczy lepiej przechowywać, bo mogą się potem przydać w razie jakiś kłopotów.
Ludzie wysyłają dziwne wiadomości i lepiej je zawsze mieć.

EDIT: zresztą jak się nie mylę to tak robią większe portale społecznościowe, a na pewno mają jakiś cel w tym.

Zrób tak jak radex_p radzi - to jest imho najlepsze rozwiązanie. Dodatkowo weź pod uwagę co pisze Sedziwoj bo faktycznie, lepiej przez jakiś czas przechowywać takie wiadomości "na zapas", nawet jeśli odbiorca i nadawca tą wiadomość usuną.
Według mnie tu zastosowanie znajdzie cron - poprostu napisz prosty skrytp, który raz dziennie uruchomisz z crona, który usunie wszystkie wiadomości oznaczone przez obu userów jako "usunięte" i starsze niż x dni.

to rozwiazanie tez wydaje mi sie najrozsadniejsze -w teorii:)
ale teraz to trzeba napisac w symfony:P
dlatego pisalem o czyms bardziej przejrzystym tak zeby jasniej to bylo napisane (kod).

Pole powinno być raczej typu SET, ponieważ wiadomość określona jest dwoma parametrami
położenie: otrzymane, wysłane, kosz
status: przeczytana, nieprzeczytana
z których można stworzyć różne kombinacje:
np: mogę przenieść nieprzeczytaną wiadomość do kosza, ale chciałbym zachować informację, że jest nieprzeczytana

jaki typ kolumn to juz mniej istotna kwestia.

ustalilismy juz jak ma wygladac tabela
podsumowujac:

[SQL] pobierz, plaintext 
CREATE TABLE `poczta` (
  `idpoczta` int(11) NOT NULL AUTO_INCREMENT,
  `temat` varchar(60) DEFAULT NULL,
  `tresc` text,
  `idprofil_nadawca` int(11) NOT NULL,
  `idprofil_odbiorca` int(11) NOT NULL,
  `przeczytane` tinyint(2) UNSIGNED DEFAULT '0',
  `status_nadawca` tinyint(2) UNSIGNED DEFAULT '0',
  `status_odbiorca` tinyint(2) UNSIGNED DEFAULT '0',
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  PRIMARY KEY  (`idpoczta`),
  KEY `poczta_FI_1` (`idprofil_nadawca`),
  KEY `poczta_FI_2` (`idprofil_odbiorca`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
[SQL] pobierz, plaintext 

kolumny status_nadawca i status_odbiorca moga przyjmowac wartosci:
0 - normalna wiadomosc
1 - wiadomosc w koszu
2 - wiadomosc usunieta

kazda akcja usuniecia zwieksza wartosc w kolumnie status_odbiorca lub status_nadawca.
czyli jak user chce przeniesc wiadomosc z folderu odebrane to zmienia sie na 1. jak chce usunac w kosza to zmienia sie na 2 i juz jej nie zobaczy nigdzie.

teraz juz pytanie techniczne
jak powinno wygladac zapytanie pobierajace dane dla akcji pokazKosz.
chcialbym tam polaczyc dane o profilach (nadawca, odbiorca).
zalozmy ze jestem zalogowany na idprofil = 2.
to bedzie cos takiego?

[SQL] pobierz, plaintext 
SELECT * FROM poczta WHERE (idprofil_odbiorca = 2 AND status_odbiorca = 1) OR (idprofil_nadawca = 2 AND status_nadawca = 1)
[SQL] pobierz, plaintext 

@AxZx
Moim zdaniem pole status powinno być FK do tabeli z statusami.

dlaczego tinyint(2) a nie tinyint(1) ?

A co to za różnica? Przecież to i tak nie ma nic wspólnego z długością pola.

Masz rację. Zapomniałem o tym. Zwracam honor

Ja bym zrobil tak:

Message:
MessageId
Title
Description
CreatedAt
ReadAt

MessageStatus:
MessageStatusId
MessageId
UserId
DirectoryId


Wyslanie wiadomosci:
1) Tworzysz rekord Message, wypelniasz odpowiednie pola, ReadAt moze byc np. null
2) Tworzysz dwa rekordy MessageStatus:
Dla wysylajacego:
jego UserId, DirectoryId na rekord slownika Directories z 'Sent'
Dla odbierajacego:
UserId - id odbiorcy, DirectoryId - 'Inbox'

Gdy odbiorca otworzy wiadomosc (i wiadomosc nie jest w DirectoryId - 'Sent'):
1) Odswiezasz rekord z MessageId wpisujac do pola ReadAt aktualna date

Usuniecie wiadomosci:
1) Sprawdzasz czy dla kazdego MessageStatus z tym samym MessageId DirectoryId wskazuje na 'Deleted' (nie 'Trash', tam sobie wiadomosci moga lezec)

Dzieki temu rozwiazaniu uzytkownicy maja niezalezna kontrole nad wiadomoscia. Rowniez mozna wysylac wiadomosci
do wielu uzytkownikow na raz, oszczedzajac miejsce w bazie danych.
Tabela MessageStatus nie musi zawierac MessageStatusId, poniewaz mozna uznac ze MessageId + UserId bedzie zawsze unikalne.
Ale to kwestia gustu.

edit:
Dla wygody mozesz potem sobie stworzyc widok w postaci

Message + MessageStatus zlaczony po MessageId

edit:
Oczywiscie nie bedzie informacji o nadawcy i odbiorcy, ale to kwestia komplikacji widoku troche Ale to niech ktos sie pomeczy bo ja spadam do domu

@superfrajer
To rozwiązanie ma jedną wadę, wymaga złączenia tabel, do tego wiadomość w serwisach społecznościowych jest wysyłana do jednej osoby, więc dwie kolumny ze statusami wcale nie są gorszym rozwiązaniem, a wydajniejszym.

nie bardzo rozumiem po co osobna tabela ze statusami. co tam ma byc przechowywane? mi sie wydaje ze w kolumnie status_odbiorca beda wartosci 0 - normalna wiadomosc, 1 - wiadomosc w koszu, 2 - wiadomosc usunieta. to tyle:)

1. Dwie tabele nie są potrzebne.
2. Zarówno status_odbiorca i status_nadawca powinny być polem SET z opcjami:
{normalna, nieprzeczytana}, {normalna, przeczytana}, {kosz, nieprzeczytana}, {kosz, przeczytana}, {usunieta, nieprzeczytana}, {usunieta, przeczytana}

I problem rozwiązany

ten ostatni przyklad komplikuje uzycie z wykorzystaniem symfony:)
dzieki temu ze bedzie osobna kolumna przeczytane moge w symfony wykonac prosty warunek

[PHP] pobierz, plaintext 
<?php
$c->add(PocztaPeer::STATUS, true);
?>
[PHP] pobierz, plaintext 

i po sprawie:)

dzieki wszystkim za odpowiedzi, chyba juz nie ma wiecej pomyslow?

@AxZx: i wróciłeś do punktu wyjścia a za odpowiedzi na priv nie dajesz pomógł?

hmm nie koniecznie.
zrobilem to w symfony - nie bylo tak strasznie. wiec to rozwiazanie jest dosyc dobre.
jeszcze tylko problem z polaceniem tabeli profil w folderze kosz - tam trzeba 2 razy laczyc tabele profil.


tym razem daje:)

Dosyc mialo być na PW, tyle zniosłem ale wystarczy. Jeszcze jedna sporna wypowiedź a dam wam po warnie jak nie moderacji postów...

Zbedne posty usunalem, jeszcze mnie tak przed urlopem denerwowac