Discussion :

[Dadj13012]

Bonjour, malgré mes recherches et différents essais, je rencontre un problème au niveau du choix de mes tables dans le développement d'une application Web au sein d'une entreprise.

Contexte:
Au poste que j'occupe, j'ai comme projet de mettre en place une interface web sécurisée ou seul mon supérieur et moi même pourront nous connecter afin d'assurer un suivi des appels et interventions informatiques.
Cette application sera développée en PHP.
Il faudra donc mettre en place une authentification sécurisée à l'application Web, ce qui apparemment engendre la création d'une table "membre" par exemple.

Ensuite, dans l'application en elle-même, il faudra que l'on puisse créer une fiche d'intervention.
Chaque fiche doit contenir un numéro unique d'intervention généré automatiquement à chaque création de fiche.

Chaque fiche unique doit comporter:

-l'identifiant utilisateur qui est de la forme: frdxxyy (xx = 2 premières lettres du prénom utilisateur, yy = 2 premières lettres du nom utilisateur)
-le nom de l'utilisateur dépanné
-le prénom de l'utilisateur dépanné
-le service dans lequel travaille l'utilisateur
-l'adresse mail de l'utilisateur de la forme: prénom.nom@entreprise.com
-la catégorie de l'intervention (s'il s'agit d'un dépannage matériel, réseau, Outlook, VPN...)
-le type d'intervention:sur le terrain ou par téléphone
-la date de l'intervention
-l'heure de début
-l'heure de fin
-la durée de l'intervention
-le statu (en cours ou résolu)
-le problème rencontré
-la solution apportée

Voila pour la base.

J'ai donc pensé créer 2 tables:

TABLE USER
FrdUser(clé primaire)
NomUser
PrenomUser
ServiceUser
MailUser

TABLE NUMERO INTERVENTION
NumIntervention(clé primaire)
Frd
Date
HeureDebut
HeureFin
Durée
Probleme
Solution
Type intervention
Categorie
Statu

Voici les questions que je pose:

1. Ces 2 tables correspondent elles au contexte évoqué (sachant que dans l'application on devra pouvoir faire une recherche avec le "frd" de l'utilisateur, la date de l'intervention, ou le statu de l'intervention) ?

2. Dois-je créer une table indépendante pour la date, l'heure début, l'heure fin et la durée?

3. Quelle forme doit avoir la table qui permettrait l'authentification à l'application Web?

Merci par avance pour vos idées et/ou conseils.

[CinePhil]

La clé primaire de la table USER risque de ne plus l'être :
Si tu as un utilisateur appelé Jean Dupont et un autre Jeanne Dumoulin, ils auront le même identifiant.
D'une manière générale, une clé primaire est de préférence une colonne de type entier auto-incrémenté.
Qu'ensuite, tes utilisateurs aient un code mnémotechnique les dientifiant de manière unique dans l'entreprise est un autre concept qui à mon avis ne doit jamais servir de clé primaire. Une autre raison à cela : Si Jeanne Dumoulin, codée aujourd'hui JEDU, se marie l'an prochain pour s'appeler Jeanne Martin, l'entreprise peut décider que désormais elle sera codée JEMA. Si ce code est la clé primaire de ta table, tu es obligé de changer également l'information dans toutes les tables liées. Alors que si la clé primaire est de type entier auto-incrémenté, tu ne changes que le code mais puisque la personne reste la même, son identifiant dans ta base de données ne change pas.

Le service pourrait être externalisé puisque je suppose que tu as plusieurs personnes par service (apparemment vous êtes au moins deux au service informatique semble t-il). Cela évite une éventuelle dissociation non voulue entre le service Comptabilité et le service Compta (saisi par un fainéant ).

Idem pour le type d'intervention, la catégorie et éventuellement le statut (peut-être y aura t-il plus de deux statuts dans l'avenir tels que 'enregistré', 'pris en compte', 'planifié', 'sous-traité', 'attente devis'...).

[Dadj13012]

Merci pour ces précisions judicieuses.
En effet le problème pourrait se poser si 2 FRD seraient identiques.
Il a été établi que si une nouvelle personne venait dans l'entreprise et que du fait de son nom et prénom, le frd qui lui serait attribué existerait déjà, on prendrait la première et troisième lettre de son prénom pour créer le nouveau frd.
Donc de ce coté la aucun problème. (Le frd est le login d'ouverture de session Windows sur le domaine.
Si qqun venait a se marier, il garderait le même FRD, donc pas de soucis non plus a ce niveau la. Je pense donc garder comme clé primaire le FRD.

Qu'en est il de la table permettant l'authentification au site en question? que me conseille tu ?

[CinePhil]

D'une manière générale, une clé primaire est un entier auto-incrémenté.
Je te déconseille l'utilisation du code alphanumérique.

Qu'en est il de la table permettant l'authentification au site en question? que me conseille tu ?

La table 'membres' que tu as envisagée peut convenir.
Tu peux aussi inclure les membres dans les 'users' en ajoutant une colonne 'membre' de type booléen à la table. Ton application testera alors si l'utilisateur qui se connecte est bien membre autorisé à accéder à l'application.

L'avantage c'est que si plus tard tu améliores ton appli pour permettre aux utilisateurs de voir où en sont les problèmes qu'ils vous ont soumis, tu pourras changer le type booleen en entier pour créer différents types d'utilisateurs membres (visiteurs qui peuvent suivre l'état de leurs demandes d'intervention uniquement, chefs de service qui peuvent voir toutes les demandes de leur service et faire des stat...) et pas besoin de duppliquer les utilisateurs qui peuvent aussi être membres.