Je suis en train de mettre en œuvre un système de notification et je vois si ces suggestions sont valides à configurer, si l'une est meilleure que l'autre ou une meilleure solution est disponible:
Une notification est ajoutée à la base de données. Un utilisateur invité / identifiable enregistre ou utilise le site. Ils sont accueillis avec des notifications qu'ils n'ont pas vu auparavant avec la possibilité de fermer ou de lire plus tard.
Ces options sont-elles une grande nécessité d'une multitude, vaut mieux ajouter potentiellement 100 000 alertes et que ces utilisateurs jettent ou interagissent avec l'avis, leur statut est modifié ou l'alerte supprimée. Cela pourrait devenir une très grande table ...
Qu'est-ce qu'un configuration plus extensible pour les notifications personnalisées en fonction de l'activité de l'utilisateur?
3 Réponses :
Je ne le ferais pas de cette façon. Je stockerais un enregistrement pour chaque (utilisateur, notification) et marquer chaque enregistrement comme lu ou non lu. Vous pouvez ensuite enregistrer quand ils le lirent, ce qui pourrait être important en fonction de votre application (par exemple, si vous aviez besoin d'une piste d'audit de quelque sorte).
100k enregistre n'est pas très grand. Ne vous inquiétez pas de la taille avant d'arriver à au moins 10 millions d'enregistrements. Si nécessaire les archiver à un moment donné. Mais vous devriez faire des estimations sur la rapidité avec laquelle vous générerez 10 millions d'enregistrements. Si c'est 3 jours, alors ouais vous avez un problème. Si c'est 3 ans, vous ne le faites pas.
Cette option bien sûr a le texte de notification dans une table séparée.
Ceci devrait également s'ajouter extrêmement bien avec un nombre encore plus élevé de messages lorsque vous sélectionnez les messages non lus pour un utilisateur (indexé) et que vous pouvez rejoindre pour obtenir le texte de notification (si votre table est dans les dizaines de millions de filières) ou sélectionnez-les puis sélectionnez séparément les messages.
partitionnement de la table (utilisateur, notification) est facile: vous base sur les gammes utilisateur.
et lorsque les utilisateurs suppriment des messages, vous devez généralement le marquer comme supprimé plutôt que de la supprimer réellement. La plupart du temps, il n'y a pas beaucoup de raison de supprimer quoi que ce soit dans une base de données.
Je veux suivre les temps de lecture, etc. et que vous dites un sentier d'audit comme vous le dites rarement si jamais supprimez, il suffit de modifier le statut en D pour supprimer par exemple. Ma principale préoccupation était la taille, alors peut-être que les notifications de lecture peuvent être ajoutées à une table séparée, sinon cela pourrait être archivé dans un fichier journal en dehors de la base de données? Je m'attends à filtrer régulièrement si une table massive causerait des problèmes. Je pense que 100 000 enregistrements par notification prendraient donc 2 semaines / millions d'enregistrements
Alternativement, vous pouvez stocker un ensemble de références aux notes qui doivent encore être lues sur une base de profil par utilisateur, puis supprimez-les lorsqu'elles sont affichées (le cas d'utilisation générale est probablement lu toutes les notes à la fois. ). De cette façon, vous n'avez qu'une minuscule requête lorsque vous tirez un utilisateur individuel et que votre coût est dans l'heure d'insertion pour le message global, plutôt que de filtrer une grande table de messages non lus.
Je codonne mon site notre site Web et j'ai la même question, mais je me suis résolu de cette façon:
lecture / non lu = vrai / faux
- Emploi Cron: Supprimer les anciennes notifications si l'utilisateur a plus de 50 notifications.
Je pense que Facebook exécute périodiquement un travail cron pour supprimer d'anciennes notifications que nous ne pouvons pas voir après que notre notification limite ait été atteinte.