SELECT & serialized array : on évite, ok ! mais comment faire ?

Bonjour,

Dans ma ptite application web, je souhaite mettre en place un système de notifications pour que certains utilisateurs soient avertis de certains événements.

Je pensais naïvement créer une table listant toutes les notifications, avec notamment une colonne qui indiquerait par quel utilisateur la notification devrait être visible via un serialized array. Mais si j'ai bien lu, ce n'est pas élégant et surtout, cela ne me permet pas facilement d'aller chercher toutes les notifications visibles par l'utilisateur 17, par exemple, puisqu'il faudrait que MySQL fouille dans ce serialized array pour voir si 17 y est inscrit.

Ok, j'évite donc cela. Mais comment faire d'autre pour que ce soit plus malin ?? Sorry pour la question probablement basique mais je cale...

Merci d'avance pour vos conseils !

T.

Bonjour,

Peut être en utilisant un système d'abonnement, chaque abonnement concerne 1 ou plusieurs événements, comme suit :

Utilisateur 0,n --- souscrire --- 0,n Abonnement 1,n --- concerner --- 0,n événements

J'suis désolé mais je ne comprends pas... Chaque notification sera stockée dans une table et j'aimerais, pour chaque notification, mémoriser la liste des userid concernés par cette notification (pour pouvoir aller facilement chercher toutes les notifications qui concernent un utilisateur en particulier)...
Le système d'abonnement me paraît compliqué, non ? (je ne le comprends pas)

Je vous ai présenté sous forme de modélisation Merise simplifiée, une solution possible à votre besoin

Un abonnement est une sorte de bouquet qui concerne 1 ou plusieurs événements (notifications)
Un utilisateur souscrit le ou les abonnements qui l'intéresse(nt)
Il suffit donc de consulter via les abonnements, quels sont les utilisateurs concernés, grâce aux tables associatives "souscrire" et "concerner"

Je commence à entrevoir une solution...

Dans ma liste des notifications comme dans ma liste d'utilisateurs, j'ai une colonne "id" unique.
Il faudrait alors que je crée une table "concerne" avec deux colonnes : la première serait l'ID de la notification et la 2e serait l'id d'un utilisateur concerné.
Du coup, quand j'ajoute une notification destinée à 3 personnes, il y a une ligne (par exemple avec l'ID 10) dans la liste des notifications et le tableau "concerne" a 3 nouvelles lignes du type "10 - 16", "10 - 8" et "10 - 45".
Et ca me permettra d'aller chercher facilement toutes les notifications pour un utilisateur donné.

C'est l'idée ?

C'est ça :)

Une table qui contient des identifiants issus d'autres tables, est une table issue d'une relation (ou association) du modèle conceptuel

Je vous avais proposé 2 relations dans mon modèle conceptuel simplifié "concerner" et "souscrire"
Votre solution est plus simple mais moins souple à l'utilisation, si elle vous convient, appliquez la :P

Ok :-) cela me suffit, pour mon usage... Mille mercis ! :-)