Création tables optimisé

Salut,

Soit tu gère cela avec 2 tables une abonnement et une utilisateur dans l'utilisateur il y aura la clé étrangère de l'abonnement quand aux options spécifique comme la date de fin d'abonnement tu la gère directe dans la table Utilisateur.

Ou sinon 3 table une abonnement avec tout ce qui est standard à abonnement, une utilisateur et une option abonnement ou il y aura la par exemple la date de fin d'abonnement avec l'id utilisateur.

Bonjour,

Merci pour ton aide

Oui je pense faire 3 tables effectivement

users(id, nom, ...)
abonnements(id, nom, delai, prix)
options(id, nom, prix)
users_abonnements(id, user_id, abonnement_id, date, prix)
users_options(id, user_id, option_id, date, prix)

Une idée comment gérer les options souscrites en cour d'abonnement et du coup payable au prorata tempori ?
une date de début et de fin pour la table users_options ?

ah oui pourquoi pas

Je bloque une nouvelle fois sur la création de mes tables.

J'ai des utilisateurs qui lors d'un traitement quotidien peuvent recevoir une notification.Suivant leurs options cette notification peut être sous la forme d'un SMS et/ou Email, ...
j'ai besoin de savoir pour un utilisateur si une notif a été envoyer par SMS, Email... et savoir si elle a était lu.

j'ai donc comme table :

la table de mes utilisateurs
USERS (id, nom, email ...)

La table contenant la liste non exhaustive mes types de notifications :
NOTIFICATIONS (id, nom, created, modified)

Et ma table de relation entre les deux :
USERS_NOTIFICATION (id, date_envoi, date_lecture, notification_id, user_id)

j'ai l'impression que cela n'est pas optimisé.

En effet si je veut la liste de toutes les noficiations envoyés à un utilisateur je dois groupé par date d'envoi

Auriez vous des remarques là dessus ?
Dois-je ajouter une table intermédiaire ?

Merci
Couss

Salut,

Les notifications sont lié à quoi exactement ? Ils y en a forcéments tous les jours ou s'est lié à quelques choses de spécifiques ?

bonjour,

il y a une vérification qui est faite tous les jours et si l'utilisateur passe en dessous d'un plafond il reçoit une notification soit par email SMS suivant ces préférences

Je trouve que c'est pas mal comme tu as fait vu que la notification est quotidienne c'est bien sur la date que cela se joue. A chaque notification envoyé à un utilisateur tu fais un insert dans la table USERS_NOTIFICATION et initiliase à null la date de lecture et des que l'utilisateur la lis tu met la date dans date lecture. Perso je trouve ta solution pas mal après c'est mon avis.
Pour savoir les notifications que l'utilisateur à recu à un jour il faut effectivement que tu filtre sur la date d'envoi.

j'ai légérement amélioré mes tables :

a table de mes utilisateurs
USERS (id, nom, email ...)

La table contenant la liste des notifications lié à un utilisateur :
NOTIFICATIONS (id, date_envoi, read, user_id)

La table contenant la liste des types de notifications envoyer lié à une notification :
NOTIFICATIONS_DETAILS (id, notification_type_id, notification_id)

La table contenant la liste des différents types de notificationss possible :
NOTIFICATIONS_TYPE(id, name, created, modified)

qu'en pense tu ?
peut être trop poussé ?
mais au moins à partir d'un utilisateur je trouve toute ces notifications, comment elles ont été envoyé respectivement ...

Oui c'est sur que comme cela c'est bien découpé tu vas un peu plus galéré coté php pour faire les insertions mais c'est plus clair.

non pas tant que ca cakephp s'en chargera
merci en tous cas