Eu tenho pesquisado como construir um sistema de notificação no SE e em outro lugar e me encontrei atraído pela solução que é a resposta aceita aqui: https://stackoverflow.com/questions/9735578/building-a-notification-system que usa esta estrutura:
╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗
║notification ║ ║notification_object║ ║notification_change ║
╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢
║ID ║—1:n—→║ID ║—1:n—→║ID ║
║userID ║ ║notificationID ║ ║notificationObjectID║
╚═════════════╝ ║object ║ ║verb ║
╚═══════════════════╝ ║actor ║
╚════════════════════╝
Uma notificação é sobre algo (objeto = evento, amizade..) sendo alterado (verbo = adicionado, solicitado..) por alguém (ator) e relatado ao usuário (sujeito). Aqui está uma estrutura de dados normalizada (embora eu tenha usado o MongoDB). Você precisa notificar certos usuários sobre as mudanças. Portanto, são notificações por usuário. Isso significa que, se houver 100 usuários envolvidos, você gerará 100 notificações.
A princípio pensei que entendia essa abordagem, mas quando comecei a me preparar para implementá-la, percebi que aparentemente não a entendia muito bem. Os últimos comentários sobre a resposta são perguntas de outros usuários que também tiveram problemas para entender a solução.
Não tenho certeza se esse é o modelo que acabarei seguindo, mas, devido ao número de votos positivos que ele tem, tenho certeza de que me beneficiaria entendê -lo e certamente gostaria de aprender mais. Espero que isso também seja útil para outras pessoas que tiveram problemas para entender essa solução (aliás, não tenho pontos de internet suficientes para deixar um comentário nessa resposta direcionando a essa pergunta, qualquer outra pessoa, por favor, faça!)
Perguntas
Se bem entendi, notificationObjectID é uma chave estrangeira apontando para a tabela notification_object e notificationID é uma chave estrangeira apontando para a tabela de notificação . Parece que o objeto deve ser uma chave estrangeira referindo-se ao ID da entrada do banco de dados sobre a notificação (por exemplo, um evento ou post específico), mas não precisamos de outro campo para indicar a qual tabela esse ID pertence?
O autor escreveu
notification_object.object identifica o tipo de alteração, como uma string "friendship" A referência real ao objeto alterado com seus dados extras sobre os quais falo está em notification_change.notificationObjectID
o que não me parece fazer sentido. Object é uma string (enum?) e notificationObjectID é uma chave estrangeira referente ao objeto de que trata a notificação? Então, como as mesas do meio e da direita estão conectadas?
Parece que a tabela do meio especifica sobre qual objeto (ou tipo de objeto) a notificação é, por exemplo, um evento ou postagem. Podemos então ter muitas entradas em notification_change que apontam para o mesmo tipo de objeto, o que nos permite agrupar notificações (como "25 usuários postados no mural de X) - daí a relação 1:n entre as tabelas do meio e da direita.
Mas por que existe uma relação 1:n entre as mesas da esquerda e do meio? Vamos dar a "25 usuários postados no mural de Sam" e "Mary atualizou seu evento "Friday Picnic" o mesmo ID de notificação? Se todas as notificações para o mesmo usuário têm o mesmo ID de notificação, por que precisamos da tabela no deixei?
Uma pergunta de desempenho - digamos que John poste um comentário sobre o piquenique de Mary. Parece que precisaríamos fazer uma pesquisa para ver se já existe um notification_object para Mary's Picnic antes de criarmos a entrada notification_change . Isso afetará negativamente o desempenho ou não é um problema? Continuando com as perguntas do parágrafo anterior, como saberíamos para qual entrada de notificação apontar o notification_object ?
Obrigado por perguntas tão completas e desculpe por toda a confusão - comentar 1 ano após a resposta inicial é difícil e agora 3 anos depois ... os pensamentos iniciais desaparecem e me confundem também, mas tenho medo de editar o buraco porque não estou trabalhando em armazenar notificações no back-end agora e não tenho certeza se faço bons julgamentos sem aplicação prática
Acho que na hora de escrever:
Portanto, tudo depende da aparência de suas notificações. Para um caso simples, você deseja apenas vincular a notificação inteira a algum URL, como a página de amigos - é por isso que ter o objeto (entityType) como uma string é útil - você vincula os URLs a ele.
A notificação "você tem 3 solicitações de amizade adicionadas" pode ser armazenada de forma diferente.
Se você quiser mostrá-los um de cada vez - você terá 3 notificações, 3 objetos de notificação (friend_request) e 3 entradas em notification_change esse link para um usuário amigo específico.
Se você quiser mostrar uma notificação - você terá 1 notificação, 1/mais objetos e 3/mais ações. Portanto, neste caso complexo, como «você tem 3 solicitações de amizade do usuário A, usuário B, usuário C» - você usa notificationObjectIDs para cada usuário e tem vários links em seu texto de notificação.
Você deve usar 1 ou 3 objetos friend_request? Isso depende de
Por outro lado, pode haver casos em que pode ser útil ter um agrupamento de ações em que nada é apagado do histórico.
Acho que é por isso que, no momento em que escrevo, a relação 1: n entre as tabelas esquerda e intermediária foi feita - para que você possa agrupar notificações não apenas por atores na mesma entidade (tabelas do meio à direita), mas também por vários objetos/entidades.
Mas claro, você pode simplificar todo o caso e otimizar o armazenamento invertendo a relação do meio esquerdo para n:1, para que você tenha notificações por usuário geradas para um evento.
Para que ficasse mais assim..
Espero que tenha ajudado