Próbuję zaprojektować system powiadamiania podobny do Facebooka i dotarłem do ściany z cegły. Moim wymaganiem jest możliwość obsługi nieskończonej liczby typów powiadomień, które mogą mieć różne typy danych meta wymaganych do renderowania.Schemat bazy danych systemu powiadomień Podobnie jak w przypadku Facebooka
myślę, że będę zaprojektować schemat następująco:
**Notification**
Id (int)
TypeId (int)
RecipientId (int)
SenderId (int)
SendDateTime (DateTime)
Read (bool)
MessageData (...Blob?)
Deleted (bool)
**NotificationType**
Id
Name
Description
naprawdę chcę unikać przechowywania ciągów HTML w mojej bazy danych, jednak, ja też nie jestem szczególnie zadowolony przechowywania plamy albo .
Możliwe, że mogę sprawdzić tablicę NotificationType i odwołać się do innej tabeli, która przechowuje dane właściwe dla tego typu, jednak oznaczałoby to, że za każdym razem, gdy utworzyłem nowy typ powiadomienia, musiałbym utworzyć nowy stół. Sądzę, że chciałbym również wkroczyć w świat pisania dynamicznego kodu SQL, aby uzyskać dane.
Czy ktoś ma jakieś sugestie dla mnie?
Pracuję nad tym samym problemem. Mam podobną strukturę jak ty, ale poszedłem z trasą html. W kolumnie opisu mam coś w rodzaju . Następnie wysyłam kwerendę do powiadomienia przez id_użytkownika i używam JavaScriptu do wypełnienia wiadomości w oparciu o identyfikatory zakresu. –
@mcottingham Mam do czynienia z tym samym rodzajem problemu, myślałem o zrobieniu czegoś podobnego tylko przechowywanie go jako XML, ale to po prostu nie wygląda dobrze ... Chciałbym móc rzucić okiem, aby zobaczyć, jak zrobił to FB .. – formatc