Discussion :

[dorian53]

Bonjour,

Etes-vous plutôt full POO ou adepte de la dénormalisation ? Et comment ?

Prenons le cas de la gestion d'un utilisateur, vous allez certainement gérer une classe User (liée à votre table en bdd).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
User
- id
- nom
- prenom
- sexe_id
...

Pour l'exemple, je souhaite m'attarder sur l'attribut sexe_id.
Au niveau d'une conception SGBDR, le sexe_id correspond à une clé étrangère.

1/ Allez-vous créer cette table sexe avec seulement deux valeurs ?
2/ Allez-vous créer cette classe sexe ?
3/ Comment allez-vous créer la méthode findAll de votre DAO Sexe ?
- Va-t-il se connecter à un SGDBR
- Va-t-il retourner deux entités Sexe ou un tableau en dur
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Sexe
- id
- nom

DAO_Sexe
- findAll()

Cet attribut est un exemple parmi tant d'autres.

Merci pour vos retours.

[CinePhil]

Normalement, un programme ne doit pas attaquer directement les tables de la BDD mais des vues, lesquelles correspondent à un Modèle Organisationnel des Données merisien et qui serait à rapprocher du diagramme de classes métier de l'application.

Dans ce cas précis, et en se limitant aux éléments que vous donnez, il y aurait une vue qui donne le libellé du sexe avec les autres données de la personne :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE VIEW v_user AS
SELECT u.id, u.nom, u.prenom,
	s.libelle
FROM user u
INNER JOIN sexe s ON s.id = u.sexe_id

Ainsi, pas de dénormalisation en BDD et pas de problème en POO.
Le tout est de demander au DBA les vues dont le programmeur aura besoin.

[dorian53]

Merci CinePhil, OK pour les vues, deux questions me viennent :
- cette donnée sexe a deux valeurs mérite-t-elle une table et une jointure ou faut-il la gérer coté code ?
- sur des référentiels qui ne bougent jamais vaut-il mieux faire une jointure ou stocker cette donnée en dur directement dans une nouvelle colonne (on peut imaginer sexe_libelle/sexe_id, ville_libelle/ville_id...).

[Richard_35]

Bonjour Dorian53 et Philippe,

- cette donnée sexe a deux valeurs mérite-t-elle une table et une jointure ou faut-il la gérer coté code ?

==> personnellement, je choisi, toujours, une table à part entière, soit :

Sexe(IdSexe, Libelle, ...)

Une partie de l'argument réside dans les points de suspension...
L'autre partie tient au fait que la valeur de la colonne Libelle peut varier :

• application multilingue ;
• norme internationale à appliquer ;
• etc...

- sur des référentiels qui ne bougent jamais vaut-il mieux faire une jointure ou stocker cette donnée en dur directement dans une nouvelle colonne (on peut imaginer sexe_libelle/sexe_id, ville_libelle/ville_id...).

==> ... a fortiori pour une entité "Ville", notamment pour les points de suspension précités.

En bref, de mon point de vue, cela ne mange pas de pain de prévoir une entité par "notion", même élémentaires, et peut se révéler salutaire pour certaines évolutions de l'application.

[dorian53]

Bonjour Richard,

C'est justement sur ce point que je m'attarde de plus en plus.

En bref, de mon point de vue, cela ne mange pas
de pain de prévoir une entité par "notion", même élémentaires, et peut se révéler salutaire pour certaines évolutions de l'application.

Tu es partisan d'une table dans l'optique que... Et c'est malheureusement bien trop souvent à cause de vouloir tout prévoir qu'on alourdit les dév.

Ne faut-il pas davantage s'attarder sur le besoin présent ? et puis le jour où le besoin évolue on adapte simplement.

À quelque chose prêt le temps d'adaptation = au temps qu'on aurait pris pour le prévoir et pour un peu que le besoin n'évolue jamais (ou qu'on ait mal prévu) on aura finalement gagné du temps.

[CinePhil]

L'autre argument pour une table de référence pour le sexe est qu'on peut avoir des utilisateurs dont on ne sait pas si c'est un homme ou une femme et qu'il faut éviter les clés étrangères nulles.

Quant à la ville, pas d'hésitation !
Absolument une table des villes !
Sinon tu risques de te retrouver avec Saint-Étienne, St. Etienne, Saint Etienne... et tu auras du mal à faire les statistiques !

En plus, une ville peut changer de nom, ce qui ne change pas pour autant le lieu de naissance de l'utilisateur. Avec une table de référence, une seule donnée à changer alors qu'avec une colonne portant le nom de la ville un peu partout dans la BDD, il faudra toutes les mettre à jour sans en oublier.

La modélisation des données doit être rigoureuse et c'est aux programmes de s'adapter aux données, pas l'inverse !

[dorian53]

En ce qui concerne la colonne supplémentaire, ce n'est qu'une copie de la valeur issue de la table SEXE ou VILLE.

Je garde la table pour les listes de référentiel et l'homogénéité de la valeur stockée.

Avoir une table avec toutes les données à plat évite les multiples jointures.

OK le cas d'une mise à jour où il faut tout update mais cette contrepartie reste exceptionnelle.

Vaut-il mieux :

1/ Une table avec les données en dur (comme un cache)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
USER
id, sexe_id, sexe_nom, pays_id, pays_nom, region_id, region_nom, dep_id, dep_nom, ville_id, ville_nom, ...

2/ Une table qui respecte les conventions + 5 jointures
La jointure vers la table SEXE est vraiment coûteuse pour pas grand chose.
Est-ce qu'on ferait la même pour un booléen avec "Oui"/"Non" ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
USER 
id, sexe_id, pays_id, region_id, dep_id, ville_id...

3/ Ou un juste milieu avec la vue qui réalise tout de même les 5 jointures.

[CinePhil]

Sans hésiter il vaut mieux le second modèle de données avec une vue qui reconstitue le premier !

Il ne faut pas avoir peur des jointures, c'est l'opération la plus optimisée dans les SGBD.

Est-ce qu'on ferait la même pour un booléen avec "Oui"/"Non" ?

Si c'est un pur booléen, ça peut être une colonne de la table.

Par exemple, si tu as des utilisateurs simples et des utilisateurs administrateurs (mais pas d'autres types d'utilisateurs), le fait qu'un utilisateur soit administrateur est une propriété de utilisateur et tu peux faire ça avec une colonne booléenne en BDD.

[Richard_35]

3/ Ou un juste milieu avec la vue qui réalise tout de même les 5 jointures.

==> ce cas n'est pas un juste milieu, c'est une conséquence du cas 2 pour lequel Philippe et moi "militons".

OK le cas d'une mise à jour où il faut tout update mais cette contrepartie reste exceptionnelle.

==> nous verrons bien quand tu devras gérer cette exception, sur plusieurs tables "références" (sexe, ville, civilité, etc...).

La jointure vers la table SEXE est vraiment coûteuse pour pas grand chose.

==> aucun coût, avec les vues.

Est-ce qu'on ferait la même pour un booléen avec "Oui"/"Non" ?

==> tu abordes, là, la partie la plus intéressante : la frontière entre la création d'une entité et la création d'un attribut. Cette frontière est assez large, mais je pense qu'en choisissant le cas 2, tu te mets à l'abris de pas mal de déconvenues.

[Luckyluke34]

1/ Allez-vous créer cette table sexe avec seulement deux valeurs ?
2/ Allez-vous créer cette classe sexe ?
3/ Comment allez-vous créer la méthode findAll de votre DAO Sexe ?

Personnellement, je privilégierais une structure de données légère de type Enum côté code.

Pas forcément besoin d'une table séparée, à part peut-être si on veut gérer la localisation/traduction des valeurs de l'enum.

Dans tout les cas, créer un DAO pour ça me parait inutilement lourd.

[souviron34]

je me permet une remarque :

1/ Allez-vous créer cette table sexe avec seulement deux valeurs ?

et les hermaphrodites ??

[CinePhil]

Pas forcément les hermapĥrodites mais on peut aussi avoir à enregistrer des personnes dont on ne connait pas le sexe. Il y a alors au moins trois valeurs : mâle, femelle, inconnu.

[dorian53]

Qu'il y ait 2 ou 4 valeurs ça ne change pas grandement le problème.

Pour chaque formulaire, ça me fait mal d'envoyer une requête pour récupérer un référentiel de 2 ou 4 valeurs.

L'autre partie tient au fait que la valeur de la colonne Libelle peut varier :
application multilingue ;
norme internationale à appliquer ;
etc...

Y a-t-il beaucoup de risques dans "etc..." parce que je peux exclure les deux premiers points.
Quand bien même, le jour ou ça doit arriver, on fait évoluer l'application.

Ne faut-il pas davantage s'attarder sur le besoin présent ? et puis le jour où le besoin évolue on adapte simplement.

À quelque chose prêt le temps d'adaptation = au temps qu'on aurait pris pour le prévoir et pour un peu que le besoin n'évolue jamais (ou qu'on ait mal prévu) on aura finalement gagné du temps.

[souviron34]

==> personnellement, je choisi, toujours, une table à part entière, soit :

Sexe(IdSexe, Libelle, ...)

Une partie de l'argument réside dans les points de suspension...
L'autre partie tient au fait que la valeur de la colonne Libelle peut varier :

• application multilingue ;
• norme internationale à appliquer ;
• etc...

Y a-t-il beaucoup de risques dans "etc..." parce que je peux exclure les deux premiers points.
Quand bien même, le jour ou ça doit arriver, on fait évoluer l'application.

Euh..

Personellement, je privilégie toujours les libellés HORS de la BD, dans une table locale toute prête multilingue...

Exemple pour le cas du sexe :

BD :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
sexe id
1     1
2     1
3     2

quand je récupère, je fabrique une chaîne "L_Sex_1", et je vais chercher sa valeur dans le fichier LOCAL (ou la table, si vraiment vous voulez quelque chose de lourd), contenant des listes comme :

Fichier local :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
L_Sex_1 { Masculin, Male, .... }
L_Sex_2 { Féminin, Female,  ... }

(ou un fichier par langue, mais il est plus difficile de maintenir la cohérence)

• L'application est automatiquement multilingue,
• les tables BD (et même locales si on veut) ne changent pas d'une langue à l'autre (on peut facilement faire une application multilignue avec changement de langue dynamique, donc ayant plusieurs langues "en live"),
• la traduction se fait facilement en envoyant le fichier directement à un traducteur...

Je considère ça comme un fichier de config plutôt que comme élément de l'appli, et donc de la base...

M'enfin c'est mon point de vue, hein ?

[Richard_35]

Bonjour à tous,

Je considère ça comme un fichier de config plutôt que comme élément de l'appli, et donc de la base...

==> le multilinguisme fait partie des règles de gestion et, à ce titre, il devrait être inhérent à l'application (dans une partie spécifique, bien entendu) :

Produit -1,n---[Posséder libellé (langue)]---1,1- Libellé

donnant :

Langue(IdLangue, ...) ;
Produit(IdProduit, ...) ;
Libellé(#IdProduit, IdLangue, Libelle, ...).

L'autre partie tient au fait que la valeur de la colonne Libelle peut varier :
application multilingue ;
norme internationale à appliquer ;
etc...

Y a-t-il beaucoup de risques dans "etc..." parce que je peux exclure les deux premiers points.

==> établir une liste exhaustive des risques est impossible d'autant que chaque élément de cette liste pourra toujours être contré.

Quand bien même, le jour ou ça doit arriver, on fait évoluer l'application.
Ne faut-il pas davantage s'attarder sur le besoin présent ? et puis le jour où le besoin évolue on adapte simplement.

==> c'est toi qui vois.

Mais, je suis d'accord, cette technique tient plus d'une sorte de discipline que nous nous imposons pour ne pas tomber dans un éventuel piège où la non-externalisation d'une donnée pourrait s'avérer catastrophique. En effet, souvent, la limite entre l'externalisation et la non-externalisation n'est pas si évidente que cela.

En revanche, l'expérience me montre que prendre des "mauvaises habitudes" conduit, parfois, à prendre de "mauvaises décisions" souvent par facilité apparente...

[souviron34]

Bonjour à tous,

==> le multilinguisme fait partie des règles de gestion et, à ce titre, il devrait être inhérent à l'application (dans une partie spécifique, bien entendu) :

Produit -1,n---[Posséder libellé (langue)]---1,1- Libellé

donnant :

Langue(IdLangue, ...) ;
Produit(IdProduit, ...) ;
Libellé(#IdProduit, IdLangue, Libelle, ...).

...

Sur ça je ne suis pas du tout d'accord, mais je ne vais pas me lancer dans un débat ici...

En effet, dans ce que tu mentionnes, que je sois en Chine, en France, ou aux US, je commande mon produit dans MA langue .. Ce produit est référencé dans TA base avec une description unique.. Que je m'appelle Jean Mohammed, John, ou Chen ne change rien à la description unique de TON stock et de ta référence.

M'enfin.. On ne perdra pas de temps là dessus...

[Richard_35]

Ce n'est pas suffisant, c'est vrai. Mais, je n'ai pas détaillé l'ensemble du paramétrage permettant de gérer le multilinguisme , ce n'est pas l'objet du fil.

[_skip]

Personnellement, je privilégierais une structure de données légère de type Enum côté code.

Pas forcément besoin d'une table séparée, à part peut-être si on veut gérer la localisation/traduction des valeurs de l'enum.

Dans tout les cas, créer un DAO pour ça me parait inutilement lourd.

+1
J'utiliserai en BDD un entier ou un char. Le sexe est une valeur dans un ensemble défini à l'avance et stable, dans le sens ou on ajoute pas 5 sexes tous les 15 jours. Je me vois pas avoir un formulaire de saisie des sexes dans une application!

Et l'application utilise des constantes ou enum pour différencier en traitement. Pour ce qui est de l'affichage et la gestion de plusieurs langues, je dirai que c'est mieux de gérer ça de façon interne à l'application quand il s'agit de textes statiques. Un peu comme l'a dit souviron.

Dans l'absolu tout le contenu multilangue qui n'est pas saisi par l'utilisateur ne devrait pas se retrouver dans les tables.