2013-06-27 38 views
9

Chcę stworzyć system komunikacji internetowej, taki jak Facebook. Mam już na myśli wiele alternatyw dla struktury bazy danych, ale nie jestem pewien, która z nich jest najlepsza. Mam tu dwie alternatywy, pierwsza to użycie dwóch tabel, druga to użycie trzech tabel, ale zrobienie cyklu w ERD.Struktura bazy danych dla internetowego systemu przesyłania wiadomości

pierwsze: Dwa stołowy, gdzie tabela wiadomość odnosi się do siebie

user 
---------- 
id 
name 

message 
-------------- 
id 
from_id 
to_id 
message_id --> refer to this table itself, to make me know which message is the topic 
subject 
content 
time 
status --> inbox, outbox, archive 
read --> read, unread 

drugie: Trzy stołowy, ale wykonać cykl w Erd

user 
---------- 
id 
name 

message_header 
-------------- 
id 
from_id 
to_id 
subject 
status --> inbox, outbox, archive 
time 

message 
-------- 
id 
message_header_id 
content 
time 
read --> read, unread 
author_id 

Osobiście lubię tę strukturę, ponieważ jest to używaj tylko jednego nagłówka wiadomości i wielu wiadomości (treść). Sam autor_id nie może zostać usunięty, ponieważ potrzebuję go, aby wiedzieć, czy wiadomość jest po lewej stronie (jako nadawca), czy po prawej stronie (jako odbiorca). Ten system jest przeznaczony tylko dla dwóch osób.

Zasadniczo ta tabela jest taka sama, ale jaka jest najlepsza praktyka wdrażania tego systemu przesyłania wiadomości? Dziękuję wcześniej.

Odpowiedz

12

Po ciężkiej nauce (dawno temu, podczas mojego ostatniego projektu ...), mogę doradzić ci oddzielenie i uporządkowanie rzeczy, kiedy to tylko możliwe. Relacja własna to miła rzecz, aby nie być blisko, jeśli to możliwe (są rzadkie wyjątki). Zaprojektuj swoje zajęcia w pierwszej instancji; zbuduj bazę danych, w której wszystko dobrze się układa, ale zachowaj wszystko tak, jak powinno być. Moje preferencje to ... lepiej niż sporządzone powiedział

Diagram


może wolisz, aby zobaczyć kod. Jest to here.
Możliwym zapytanie do listy wiadomości z pewnego nagłówku byłby

SELECT 
    h.id AS `header_id`, h.`subject`, h.`status`, 
    m.id AS `message_id`, m.content, m.`time`, 
    IF(m.is_from_sender, x.`name`, y.`name`) AS `written_by` 
FROM (SELECT * FROM header WHERE id = @VAR) h 
    INNER JOIN message m ON (h.id = m.header_id) 
    INNER JOIN user x ON (h.from_id = x.id) 
    INNER JOIN user y ON (h.to_id = y.id); 
  • Zobaczysz osobistych preferencji kopalni pól bitowych. Na przykład, nie musisz pamiętać pewnej wartości from_id więcej niż jeden raz, gdy twoim celem jest system komunikacji dwu osób.
  • Mam nadzieję, że masz wątpliwości.

Pozdrawiam,

Leonardo

+0

Jeżeli wiadomość jest przykuty przez kolejności odpowiedzi na pewnej wiadomości lub powinny one być wymienione zgodnie datownik – aeonsleo

+0

Korzystanie zamówienia odpowiedź (wyższe IDS pierwsze) może być trochę tańsze, ale możesz wziąć pod uwagę zamawianie znaczników czasu (oczywiście z odpowiednim indeksem) bardziej przyjaznym w przypadku, powiedzmy, że ktoś odpowiada bez internetu i potrzebuje trochę czasu, aby skutecznie wysłać wiadomość do bazy danych. Powiedziawszy, decydujesz:> –

+0

Jaki jest pożytek z atrybutu "is_from_sender"? –