Bonjour,
J'aimerai beaucoup être conseillé sur le stockage des informations de références
dans un système de base de données relationnelles.
J'ai quelques exemples à l'esprit :
Prenons la table t_pers_prs, d'état civil suivante :
kn_prs(pk),t_matricule(ak),t_nom,t_prenom,t_sexe,d_datenaiss,t_villnaiss
Dans une table d'état civil, je vais indiquer homme ou femme, comme propriété.
Le domaine de ma propriété t_sexe, aura uniquement 2 valeurs possible,
du coup, je choisis d'inclure le champ t_sexe, dans la même table, sans créer de table de référence. (ok ?)
Est-ce que je dois stocker dans ce champ aux données redondante, la valeur la plus courte possible
d'1 caractère M ou F, quitte à convertir par fonction M->masculin, F->féminin, à chaque requête ?
Est-ce que je dois stocker en toutes lettres masculin, féminin ?
A ce sujet, je constate une première réponse de SQL PRO, avec la création d'une table de référence M/F
Dans mon même exemple, je dispose d'un très grand nombre d'occurences de villes
différentes, au point où je choisis d'élever cette information au rang de propriété. (ok ?)
Dans mon exemple, quelle devrait être mon organisation, si je voulais également stocker
ville de naissance, département de naissance, région de naissance et pays de naissance ?
Combien de tables est il judicieux de créer ?
Y a t il une règle à savoir, qui serait liée, notamment, à l'usage que l'on fera de chaque information ?
Autre question :
Parfois, le gestionnaire ne connaît pas à l'avance,
la valeur qu'il voudra mettre comme référence, pour catégoriser une information donnée.
Dois-je en ce cas, systématiquement, réserver une table de référence et permettre
à mon gestionnaire d'y stocker progressivement de plus en plus de références de son choix ?
Autre question :
A partir de quel nombre de valeurs distinctes d'un domaine de référence, crée-t-on une table séparée contenant cette référence ?
Quelles les inévitables questions à se poser avant
de créer ou non, une table de référence ?
Merci beaucoup pour vos précieux conseils !
Partager