Discussion :

[martinbrait]

Bonjour à tous !

Pourquoi devrait-on mettre en œuvre une liste de valeurs ?
Pourquoi devrait-on mettre eu œuvre une table de références ?

Ceci reprend une discussion précédente :

Les tables de référence sont chez moi, comme le suggère SQLPro, des tables dont le contenu
change peu,
vient d'une référence externe à la BDD (nomenclatures),
est destiné côté applicatif à remplir des listes et/ou de l'auto-complétion après la saisie des premiers caractères.

Cas typiques :
- tr_sexe_sex (sex_id, sex_code, sex_libelle, sex_ordre) => sex_ordre est destiné à définir l'ordre d'affichage dans une liste
- tr_civilite_civ (civ_id, civ_abreviation, civ_libelle, civ_ordre) => civ_ordre : idem ci-dessus
- tr_pays_pay (pay, id, pay_code_iso, pay_code_insee, pay_nom_original, pay_nom_francais) => pay_code_insee et pay_nom_francais pour une utilisation française mais pas obligatoire (on peut faire un héritage pour les utilisations nationales, ou autres solutions de traduction...)
- tr_region_reg (reg_id_pays, reg_numero, reg_code_local, reg_abreviation, reg_libelle) => Identification relative au pays car la notion de région existe ou peut s'appliquer sous différents noms à plusieurs pays (lander en Allemagne, generalitat en Espagne, canton en Suisse... là aussi, plusieurs modélisations sont possibles)
- tr_departement_dpt (dpt_id, dpt_numero, dpt_nom) => dpt_numero sur 3 caractères à cause des départements d'outre-mer et, bien sûr, cette notion ne s'applique qu'à la France.
- tr_ville_vil (vil_id, vil_id_pays, vil_nom_original, vil_nom_francais)
- th_ville_francaise_vlf (vlf_id_ville, vlf_id_departement, vlf_code_insee...) => Bien sûr pour une application française !
- tr_monnaie_mon (mon_id, mon_abreviation, mon_symbole, mon_nom...)
- tr_type_produit_tpr (tpr_id, tpr_code, tpr_libelle_tpr_ordre)
- tr_type_adresse_tad (tad_id, tad_code, tad_libelle, tad_ordre)

LISTE DE VALEURS :
Abordons le côté des conséquences SQL :
Une liste de valeur nous économise une jointure, lors de la restitution de la valeur, dans une requête de projection (SELECT)
Point fort :
simplicité pour restituer le contenu de la colonne
Point faible :
une fois la liste de valeurs établie par le développeur, celle ci n'est plus modifiable par le gestionnaire.
exemples de listes de valeurs, on choisit des valeurs universelles,
qui ont peu de risque d'être supplantées par d'autres, actualisées, tout au long de la vie de l'application.
tr_sexe_sex (sex_id, sex_code, sex_libelle, sex_ordre)
tr_pays_pay (pay, id, pay_code_iso, pay_code_insee, pay_nom_original, pay_nom_francais)

TABLE DE REFERENCES
Une table de références inventorie des valeurs
directement liées au domaine
réorganisables tout au long de la vie de l'application
Cette table de références devrait toujours contenir

• une date de début d'utilisation de la référence,
• une date de fin d'utilisation de la référence,
• un ordre d'affichage personnalisé, si différent de l'ordre d'affichage alphanumérique

tr_region_reg (reg_id_pays, reg_numero, reg_code_local, reg_abreviation, reg_libelle, reg_debactif,reg_finactif,reg_ordaffich)
tr_departement_dpt (dpt_id, dpt_numero, dpt_nom,dpt_debactif,dpt_finactif,dpt_ordaffich)
tr_ville_vil (vil_id, vil_id_pays, vil_nom_original, vil_nom_francais,vil_debactif,vil_finactif,vil_ordaffich)


TABLE DE REFERENCES AVEC SIMPLE ACCES AUX VALEURS
la table de références n'autorise pas l'ajout ou la modification de valeurs par le gestionnaire.
pas de difficulté particulière

TABLE DE REFERENCES AVEC AJOUT/MODIFICATION DES VALEURS
la table de références autorise l'ajout de valeurs par le gestionnaire;
Point fort :
remplissage évolutif, sans connaissance de toutes les références au départ de l'application
complété au fil de l'eau, par le gestionnaire (utilisateur de l'application),selon ses choix vraiment personnels (non influencés)

Point faible :
Le gestionnaire qui complète la liste de référence au fil de l'eau, ne connaît pas les règles informatiques d'atomicité :
il choisit après coup, de mélanger département, ville, région dans une seule colonne, initialement prévue pour une ville -> lieu-dit
il saisit plusieurs villes au lieu d'une seule, dans la colonne

Je conclue à la hâte de la manière suivante :
1) créer en premier choix, des listes de valeurs, au lieu des tables de références, dès que la réalité stockée est "universelle".
L'universalité de la référence stockée est à chercher parmi les références liée au thème de gestion indirectement.

2)créer en deuxième choix, des tables de références, sans possibilité d'ajouter/modifier des nouvelles valeurs.


3)créer en troisième choix, des tables de références, avec possibilité d'ajouter/modifier de nouvelles valeurs.
- mettre les colonnes remplies par les gestionnaires sous-surveillance
- détecter et corriger le plus tôt possible les références aberrantes , saisies par les gestionnaires
- accepter de remettre en cause le cahier des charges, en cas d'apparition d'anomalies