Eu estive estudando como criar um sistema de notificação no SE e em outros lugares e me senti atraído pela solução que é a resposta aceita aqui: /programming/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 alterações. Portanto, são notificações por usuário. Ou seja, se houver 100 usuários envolvidos, você gera 100 notificações.
A princípio, pensei que havia compreendido essa abordagem, mas quando comecei a me preparar para implementá-la, percebi que aparentemente não a entendia particularmente 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, dado o número de votos que ele possui, tenho certeza de que me beneficiaria de 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 sobre a resposta direcionada a essa pergunta, mais alguém por favor!)
Questões
Se entendi direito, notificationObjectID é uma chave estrangeira para a notification_object mesa, e notificationID é uma chave estrangeira apontando para a notificação de mesa. Parece que o objeto deve ser uma chave estrangeira referente ao ID da entrada do banco de dados da qual a notificação se refere (por exemplo, um evento ou publicação específica), 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 parece fazer sentido para mim. O objeto é uma string (enum?) E notificationObjectID é uma chave estrangeira que se refere ao objeto sobre o qual a notificação se refere? Então, como as tabelas 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 se refere, por exemplo, um evento ou publicação. 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í o relacionamento 1: n entre as tabelas do meio e da direita.
Mas por que existe uma relação 1: n entre as tabelas 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 tiverem o mesmo ID de notificação, por que precisamos da tabela na tabela esquerda?
Uma questão de desempenho - digamos, John postou um comentário no evento de piquenique de Mary. Parece que precisamos fazer uma pesquisa para ver se já existe um objeto de notificação para o Mary's Picnic antes de criarmos a entrada notification_change . Isso afetará negativamente o desempenho ou não será um problema? Continuando as perguntas do parágrafo anterior, como saberíamos para qual entrada de notificação apontar o objeto notification_object ?
fonte
