Discussion :

[pierrot10]

Hello à tous,

Je travaille sur schéma et je suis emprunté en ajoutant une table qui doit contenir des informations liées à une sonde et à l'ID d'une station. Cette table peut contenir plusieurs fois les informations sur la même station et la même sonde ainsi que d'autres.

J'ai donc ajouté une table n:m. J'ai ceci



Je constate que les deux lignes sont continues.

Précédemment, j'ai ajouté

1. une tables 'users' et 'roles' et un role est attribué à un utilisateur (super admin, admin, user, ghest, demo).
2. une table users_has_fields. Catte table contient les utilisateurs qui sont autorisés à consulter certain(s) terrain(s). (Un terrain contient des stations). Un role est aussi attribué dans cette table afin de définir les droits aux utilisateurs sur le terrain

Par exemple

1. si un utilisateur qui a le droit sur un terrain avac le role user, il ne pourra que consulter l'état des stations de CE terrain
2. si un utilisateur qui a le droit sur un terrain avac le role admin, il ne pourra modifier les seuils des sondes des stations de CE terrain
3. si un utilisateur à le role SuperAdmin, il aura tous les droits sur cette station/terrain quelque soit le role qu'il a dans 'user_has_field'. Il pourra donc modifier les seuils des sondes de cette(ces) station(s)

Ca fonctionne très bien.

Simplement quand je regarde mon schéma

je vois que la table 'users_has_fields' a les lignes en trait tillé entre la table 'users' et 'fields'

Je me demande quelles seront vos critiques.

En premier temps, je pensais avoir fait la table 'users_has_fields' n:m entre 'fileds' et 'users' et je me demande si j'aurais dû le faire, ..et ensuite ajouté une table 'role' en deux fois 1:n.

Est-ce que ca vous fait sauter de votre siège et que je devrais passer un peu de temps à repenser à ca?
Ou ca va comme cela, puisque que ca fonctionne bien comme cela.

Ne soyez pas trop dur dans vos critiques, su vous sautez de vos sièges

Merci et belle soirée

[pierrot10]

Dans mon précédent message, dans la table 'users_has_fields', les lignes 'sensors_id_sensor' et 'stations_id_station' ne peuvent pas avoir une clé primaire, car le sensors d'une station peut être en alarme plusieurs fois à une date différente. Donc ces deux champs ne seront pas avec une valeur unique. En décochant PK, j'ai ceci


J'ai pas encore créé la ligne 'date'

[fsmrel]

Bonsoir,

Je constate que les deux lignes sont continues.

Cela veut dire que les attributs (clés étrangères) sensors_id_sensor et stations_id_station participent à la clé primaire de la table alarm_histories.

je vois que la table 'users_has_fields' a les lignes en trait tillé entre la table 'users' et 'fields'

Cela veut dire que les attributs (clés étrangères) fields_id_field et roles_id_role ne participent pas à la clé primaire de la table users_has_fields.


Voyez Modéliser les données avec MySQL Workbench

[escartefigue]

Bonjour Pierrot10

Il est plus facile de vérifier la cohérence d'un MCD avec les règles de gestion que celle d'un MLD produit par MySQL Workbench.

Quelques remarques :

• pourquoi définir des données latitude et longitude de type décimal, alors qu'il existe des types de données "géography" prévus pour cet usage ;
• il ne faut pas utiliser systématiquement du varchar pour les types caractère. Le char fixe est préférable pour les petites longueurs (approximativement moins de 20 caractères), car le varchar engendre des problèmes de performances dans certains cas.
  Par exemple, pour le code pays, si vous utilisez la norme ISO 3166, la longueur est soit de 2 soit de 3 caractères ;
• une adresse courriel sur 45 caractères n'est pas suffisante : l'adresse locale (avant le caractère @) peut faire jusqu'à 64 caractères et le nom du domaine et l'extension (après le @) peuvent contenir jusqu'à 255 caractères.
  Voir ICI ;
• à l'inverse, un mot de passe de 255 caractères me semble très peu réaliste... Qui saura mémoriser un tel MdP ?