Simplification de modèle relationnel et avis sur le type SET [Résolu]

[Djakisback]

Bonjour,
d'une manière générale, j'ai toujours essayé de respecter les formes normales et le principe de l'atomicité des données lors de la conception d'un modèle relationnel. Je me suis souvent retrouvé avec des modèles très complexes et les requêtes qui en découlent (et qui d'ailleurs au final peuvent poser de légers problèmes de consommation des ressources).

Je me demandais s'il existait des moyens (propres ou non au SGBD) pour simplifier tout cela. Si je prends un cas d'étude simple pour lequel un 'document' peut être lié à plusieurs 'types', ex. : un 'document' peut être de type 'Roman' et 'Poésie'

En général, j'ai tendance à procéder ainsi, avec 2 tables + 1 table de jointure :

Code :

1
2
3
4
5
6
7
8
document
d_id | d_titre
 
type
t_id | t_intitule
 
j_type
d_id | t_id

jeu de données qui donnerait :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
document
d_id | d_titre
1 | Le Val de Rose
 
type
t_id | t_intitule
1 | Roman
2 | Poésie
 
j_type
d_id | t_id
1 | 1
1 | 2

Tout d'abord, pensez-vous qu'il s'agit d'une bonne méthode dans le cas où la table 'type' n'est liée à aucune autre table et qu'en plus un enregistrement ne contient qu'un champ de donnée (i.e. ici l'intitulé) ? Y a-t-il une meilleure méthode ou plus communément utilisée ?

Je suis en train de réfléchir à l'utilisation du type SET qui pourrait peut-être répondre à ce type de besoin.

Auriez-vous des avis ou conseils sur l'utilisation du type SET ou sur d'autres techniques qui pourraient exister et simplifier les modèles et les requêtes dans ce même cas d'étude ? Sinon connaissez-vous des désavantages au type SET ? (ressources, recherches partielles/totales, souplesse, problèmes d'index ...)

En vous remerciant d'avance.

[Waldar]

Je n'ai pas d'avis sur le type SET, mais ce que vous faites est bien la bonne méthode.

[punkoff]

Bonjour,

Tout d'abord, pensez-vous qu'il s'agit d'une bonne méthode dans le cas où la table 'type' n'est liée à aucune autre table et qu'en plus un enregistrement ne contient qu'un champ de donnée (i.e. ici l'intitulé) ? Y a-t-il une meilleure méthode ou plus communément utilisée ?

Oui, non, non.

Je suis en train de réfléchir à l'utilisation du type SET qui pourrait peut-être répondre à ce type de besoin.

Auriez-vous des avis ou conseils sur l'utilisation du type SET ou sur d'autres techniques qui pourraient exister et simplifier les modèles et les requêtes dans ce même cas d'étude ? Sinon connaissez-vous des désavantages au type SET ? (ressources, recherches partielles/totales, souplesse, problèmes d'index ...)

Oui, pour moi c'est une très mauvaise idée.

Je ne comprend pas en quoi la requête est compliquée en fait ? Faire 1 ou 2 jointures de plus est si fatiguant que ca ?

Pour les désavantages que je vois (vu qu'on ne connait pas votre SGBD...) :
- Maintient horrible : obliger de faire un alter table pour ajouter / enlever une occurance du set
- Requête pas vraiment simplifiée vu qu'il faudra utiliser des fonctions spécifique au sgbd pour arriver à travailler avec les set
- Peut devenir source de contention / lock si forte activité autour de la table document ou affectation d'activité (plus qu'une table au lieu d'une table d'association)
- Est-ce les update / delete, sur votre SGBD seront aussi performant ? (c'est facile à tester)

[Djakisback]

Merci beaucoup pour vos réponses et conseils

A la base, je pensais à la solution du SET (ou autres) dans le but d'optimiser les exécutions de requêtes mais aussi leurs écritures. Il me semble que cela simplifierait pas mal le code étant donné qu'on peut beaucoup réduire le nombre de tables.
Comme dans certains modèles complexes, on peut parfois se retrouver avec plus d'une dizaine de jointures, je pense que ça pourrait réduire la complexité du code des requêtes mais aussi les ressources étant donné qu'on fait des SELECT sur moins de tables. (En fait, parfois ça n'est pas une ou deux jointures de moins que l'on aurait, il me semble que j'ai des modèles où cela en supprimerait bien 5 ou 6, mais peut-être que je suis trop gourmand sur ce que je veux récupérer en une seule fois)

Il est vrai que les ALTER TABLE pour un SET/ENUM ne m'ont jamais inspiré ; sur ce coup-là j'étais plutôt dans une optique de sélection des données (sur un modèle statique, si je puis dire) plutôt que d'insert/update/delete, car c'est plutôt sur des SELECT que je peux parfois rencontrer quelques problèmes de performance mais ça semble mauvais de penser un modèle uniquement pour un type de traitement. (Et il y a sans doute d'autres optimisations que je puisse faire dans des modèles/scripts avant de "bousiller" des modèles de données )

En fait, je croyais que SET et ENUM faisaient partie de la norme SQL et apparemment non, ce qui me dérange fortement. Je pense que je ferai des tests par curiosité mais je vais suivre les conseils et continuer dans la voie que j'ai suivie jusqu'ici. (Merci pour les désavantages proposés, 3 sur 4 auxquels je n'avais pas pensé)

Je me posais encore 2 petites questions, si l'on respecte la norme SQL, le principe des formes normales, et que l'on veut stocker des "titres/qualificatifs" de personnes (Monsieur, Madame, Abbé, etc.), on aura également 3 tables dont une d'association ?

Question un peu plus vague et sans doute un peu trop lié au SGBD mais cela vous arrive-t-il parfois de ne pas faire toutes les jointures nécessaires au jeu de données attendu en une seule requête mais, à partir de l'exemple extrêmement restreint présenté dans mon premier post, de récupérer tous les documents puis exécuter un nouveau SELECT pour chaque document afin de récupérer des données périphériques liées. Cela augmente considérablement le nombre de requêtes mais, dans mon souvenir, j'ai eu parfois de meilleurs performance dans certains cas. Auriez-vous des avis quelconques sur ce type de pratique ?

[Rei Ichido]

Envoyé par Djakisback

Je me posais encore 2 petites questions, si l'on respecte la norme SQL, le principe des formes normales, et que l'on veut stocker des "titres/qualificatifs" de personnes (Monsieur, Madame, Abbé, etc.), on aura également 3 tables dont une d'association ?

Non, deux seulement, à moins que tu ne veuilles avoir des personnes pouvant avoir plusieurs titres.

Question un peu plus vague et sans doute un peu trop lié au SGBD mais cela vous arrive-t-il parfois de ne pas faire toutes les jointures nécessaires au jeu de données attendu en une seule requête mais, à partir de l'exemple extrêmement restreint présenté dans mon premier post, de récupérer tous les documents puis exécuter un nouveau SELECT pour chaque document afin de récupérer des données périphériques liées. Cela augmente considérablement le nombre de requêtes mais, dans mon souvenir, j'ai eu parfois de meilleurs performance dans certains cas. Auriez-vous des avis quelconques sur ce type de pratique ?

Si cela arrive, c'est que le SGBD ne raisonne pas bien Probablement par manque d'infos au niveau des stats. Cela dit, unitairement (ie quand je passe des requêtes à la main), ça m'arrive assez souvent de le faire, mais c'est plus par flemme d'écrire une requête complète et pour avoir accès à des informations intermédiaires si les résultats ne me vont pas. Pour les requêtes "applicatives", j'essaie de réduire au maximum le nombre de requêtes.

[Djakisback]

Merci, il faudrait que je me forme un peu plus en administration de base de données pour mieux comprendre ces principes-là.

Envoyé par Rei Ichido

Non, deux seulement, à moins que tu ne veuilles avoir des personnes pouvant avoir plusieurs titres.

merci, effectivement. (En général j'utilise majoritairement le ENUM pour ces cas-là).

[estofilo]

Envoyé par Djakisback

Je suis en train de réfléchir à l'utilisation du type SET qui pourrait peut-être répondre à ce type de besoin.

Auriez-vous des avis ou conseils sur l'utilisation du type SET ou sur d'autres techniques qui pourraient exister et simplifier les modèles et les requêtes dans ce même cas d'étude ?

Tout d'abord SET n'est pas un type répandu dans les SGBDs. Supposons qu'on parle en fait ici de mysql, dont la doc présente le type SET comme assimilable à un champ de 64 bits.
Ca, on peut toujours le faire dans tous les SGBDs avec un entier pour une taille fixe ou une chaine de caractères, ou même un champ binaire sans taille max.

Dans certains cas spécifiques ça peut effectivement être très performant. Par exemple pour associer jusqu'à 32 tags à des documents dans un champ de 32 bits, on peut savoir si tel document a les tags A et B et n'a pas les tags D ou E en lisant uniquement un champ entier dans la table document sans aucune jointure. Cette lecture est beaucoup plus performante qu'une multi-jointure sur une table (doc_id,tag_id) et le gain de place est également considérable.

[Djakisback]

Effectivement, pour ce type d'opération, dans le sens gestion de flags si je comprends bien, ça semble intéressant. Apparemment, on doit pouvoir travailler aussi directement en binaire dessus. Merci pour cette précision, j'avais zappé ça dans la doc MySql

[CinePhil]

Quelques bonnes pratiques...

1) Construire un modèle de données normalisé au maximum.

2) Utiliser des vues.
Ce sont elles qui vont éventuellement contenir des jointures multiples mais ensuite les requêtes applicatives sur les vues sont beaucoup plus simples.

3) Ne récupérer que les informations dont on a besoin.
Si vous voulez afficher une liste de documents avec juste le titre et l'auteur, inutile de récupérer sa version, sa date de création, de révision, le texte du résumé...
C'est ensuite lors du clic sur le titre du document qu'on aura besoin d'afficher d'autres informations.
Il ne faut pas multiplier les requêtes inutiles mais il faut faire les requêtes nécessaires.

4) Si vous avez un grand volume de données (à partir de plusieurs centaines de milliers de lignes dans certaines tables), prototypez la montée en charge sur les requêtes les plus gourmandes pour voir "si ça tient".
Identifiez les points chauds et commencez par tester la modification et/ou la création d'index.
Ensuite seulement, vous pourrez vous pencher sur la dénormalisation de certaines données, toujours en mesurant les résultats sur votre prototype.

Voir au sujet des index l'article de SQLPro.

[Djakisback]

Merci pour ces conseils supplémentaires.
Je pense être au point avec les points 1, 3 et la gestion des index mais n'ai jamais pratiquement utilisé les vues et ne connaît pas bien l'administration de BDD, il faudra que je m'y mette à l'occasion.