Forum PHP.pl

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

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

Ten post edytował tiraeth 31.07.2008, 22:23:25

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:)

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.

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

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

Ten post edytował superfrajer 1.08.2008, 19:07:24