Discussion :

[cipic]

Bonjour à tous,

Excusez-moi tout d'abord si je ne suis pas au bon endroit.

Étant en phase d'apprentissage de pHp et MySQL en tant que hobby, je cherche à concevoir un site de jeu de rôle.

La gestion des bases de données relationnelles m'a beaucoup intéressé. Je viens de lire la première partie du cours de Cyril Gruau sur la conception de bbd, concernant le Modèle de Données Conceptuel : une découverte complète pour moi (novice complet dans le domaine) qui m'a paru d'une grande puissance.

Je me suis dit qu'il fallait s'en servir également pour gérer l'affichage des différentes descriptions d'objets ou de lieux apparaissant dans le jeu en fonction de la langue sélectionnée par le joueur.

J'ai donc, armé de mon crayon à papier, tenté de concevoir le schéma conceptuel qui correspondait. C'est là que je me suis rendu compte que je n'arrivais pas du tout à dessiner mon schéma : je ne sais si mes différentes langues doivent être regroupées dans une table langues (id, nom de la langue) associée à une table contenant toutes les textes du jeu, ou bien chaque langue sur une table avec uniquement les textes de la langue concernée ; ni comment relier tout cela avec le reste des tables du jeu.

Je me pose donc de nombreuses questions :

- la gestion relationnelle des bdd est-elle le bon outil pour gérer l'affichage des langues ?
- connaissant les bases des duos html/css et php/mysql ainsi que des concepts de gestion des bdd relationnelles, ai-je les moyens de coder un tel système ?

étant autodidacte, je ne possède pas les bases "académiques" de la programmation, donc je crains de m'y prendre par le mauvais bout dès le début...

Des éclaircissements seraient donc les bienvenus !

merci

[fsmrel]

Bonjour,

je ne sais si mes différentes langues doivent être regroupées dans une table langues (id, nom de la langue) associée à une table contenant toutes les textes du jeu, ou bien chaque langue sur une table avec uniquement les textes de la langue concernée

Si vous choisissez de prévoir une table par langue, à chaque fois que vous aurez à ajouter une langue, il faudra modifier la structure du modèle, ce qui n’est pas recommandé. En plus, comme vous raisonnez en termes de tables, il y a du SQL pour accéder à celles-ci, et il faut donc les nommer :

Select ....
From table_en_français
Where ...

ou

Select ...
From table_en_espagnol
Where ...

ou

...

Chaque requête devra exister en autant de versions qu’il y a de langues, à moins de se lancer dans du SQL dynamique. Bref, ça n’est pas un bon plan.

Supposons maintenant qu’à un événement donné corresponde un texte donné. Si ce texte doit être présenté selon la langue, une amorce de MCD associant Événement et Langue pourrait être :



Au format tabulaire, Presenter a l'allure suivante :

Code :

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

1
2
3
4
5
6
7
8
 
EvenementId   LangueId   Texte
    e1          l1       Bonjour 
    e1          l2       Buenos dias 
    e1          l3       Guten tag
    e2          l1       Bonne nuit
    e2          l2       Buenas noches
    e2          l3       Gute nacht

[CinePhil]

Avec des identifiants de type entier, ce serait encore mieux !

[fsmrel]

Avec des identifiants de type entier, ce serait encore mieux !

Certes, quand la base de données prendra vraiment forme, il sera nécessaire de bien définir le type des données, mais au stade où nous en sommes, cet aspect des choses est orthogonal (indépendant) au problème posé par cipic. Au niveau du MCD embryonnaire et de l'exemple qui l'accompagne, il n'est pas mauvais d'utiliser des mickeys, des choses qui parlent.

[pascalbuguet]

bonjour,
Merise2 propose 4 niveaux (conceptuel, organisationnel, logique et physique)
Au niveau conceptuel (et nous y sommes) il est préférable de décomposer au maximum donc de créer une entité "dictionnaire" ou "lexique" .... pour éviter les redondances.
Au niveau logique et surtout physique (SQL) en fonction des jointures (très coûteuses) le modèle pourra être dénormalisé en 2NF.

bonne soirée

[fsmrel]

Bonsoir,

Au niveau conceptuel (et nous y sommes) il est préférable de décomposer au maximum donc de créer une entité "dictionnaire" ou "lexique" .... pour éviter les redondances.

Non sequitur. Je ne vois pas la relation de cause à effet entre le fait de décomposer au maximum et créer une entité "dictionnaire". Expliquez-vous.

Par ailleurs, éviter les redondances est évidemment impératif, mais je ne vois toujours pas la relation avec ce qui précède.

Pardonnez-moi, mais on dirait du Molière (voyez Le médecin malgré lui).

Au niveau logique et surtout physique (SQL) en fonction des jointures (très coûteuses) le modèle pourra être dénormalisé en 2NF.

Légende : une jointure n’est pas coûteuse a priori. Certaines jointures entre des tables de cent millions de lignes coûtent de l’ordre de la centaine de millisecondes. D’autres, entre des tables de dix mille lignes peuvent durer des heures. Tout dépend du rendement de l’effet I/O bound versus CPU bound, du filtrage des lignes, de l’organisation des index, du taux de désorganisation, du SGBD, etc. Mais mon langage de DBA de terrain vous déroutera peut-être.

Pour information, la table Presenter que je propose à cipic respecte la 5e forme normale et vous m’expliquerez ce que l’on peut lui reprocher.

Par ailleurs, on ne « dénormalise » pas un modèle, mais une table (si tant est que l'on prouve qu'il faille le faire). Et puis, pourquoi choisir de dénormaliser très précisément en 2NF plutôt qu'en une autre xNF ? Par exemple, de 5NF en 4NF ?


P.-S.

Merci de nous donner votre définition de la 2NF. En échange, je vous propose celle de la 5NF :

Une table T (en 1NF) est en 5NF (ou PJ/NF, Project/Join Normal Form) si et seulement si chaque dépendance de jointure non triviale à laquelle elle satisfait est une conséquence logique des clés candidates de T. (« Conséquence logique » signifiant en l’occurrence : pour chacune de ces dépendances de jointure *{R1, ..., Rm}, chaque Ri (1 ≤i ≤m) est une surclé de R).

Et à titre de complément :

Une table est en 1NF si chacun de ses tuples contient exactement une valeur pour chacun de ses attributs.

[pascalbuguet]

bonjour,
chipotons fsmrel !
Le cas présenté par citic (en phase d'apprentissage) ne nécessite pas des considérations de NF4 ou NF5 (par ailleurs très peu appliquées et hors sujet pour le propos). Donc oublions-les pour l'instant.

citic veut savoir s'il doit créer une table "lexique" ou plusieurs.
Je lui en recommande une.

Par ailleurs pour le coût des jointures.
Vous avez raison sur certains points : en pratique le SGBDR, le disque ... fera la différente. Ce n'ai pour rien qu'à une époque SYBASE a pris de l'avance sur les autres 3 autres tigres (Oracle, DB2, Informix) en créant des semi-jointures.
Par ailleurs à une certaine époque Oracle (qui peut rester notre référence) fournissait des équations sur les calculs d'accès.
Une jointure est plus coûteuse qu'un select sur une seule table dénormalisée en FN2.
Un administrateur vous le dira, la tête de lecture se promène plus sur plusieurs clusters.
Mr CODD (in english) et mr Gardarin (en français, un maître en la matière à Jussieu à l'époque aussi) vous le diront.

Les exemples de dénormalisation en FN2 ne manquent pas.

Pour terminer je vais vous raconter une anecdote concernant le MOSSAD (vous ne le répéter pas!).
Le MOSSAD voulait connaître les "amis" d'Arrafat.
Et fit donc une auto-equi-jointure.
Et son serveur explosa.
... Il trouva une solution : réduire le nombre de jointures !

Bonne soirée

PS : le problème c'est que je ne crois pas que cipic soit plus éclairé, or le but de notre présence ici c'est de l'aider et non pas de montrer notre modeste savoir; il doit y avoir d'autres lieux pour nous "amuser"

[cipic]

Héhé je dois dire qu'en effet, étant en phase d'apprentissage, je ne comprends pas bien les tenants et les aboutissants des subtilités évoquées...

Une proposition qui m' été faite ailleurs est d'utiliser une classe d'objets "texte" de pHp5, conjuguée à une librairie par langue. Chaque texte possède un identifiant, et la classe s'occupe d'appeler le texte en fonction de la langue choisie par l'user.

cela me semble une bonne solution puisque pour ajouter une langue, il suffit de dupliquer le fichier contenant des textes et de le traduire, un identifiant de la langue faisant le reste.

Mais cela m'amène à un problème plus général, et donc qui n'a peut-être pas sa place ici : quelles sont les données qui doivent être enregistrées dans une bdd puisque celles-là n'ont pas besoin de l'être !?

En fait j'apprends un peu tout en même temps par moi-même (pHp/MySQL/programmation orientée objet, conception de BDD) et donc la structure me manque .
J'ai du mal à savoir si un problème est inhérent à la conception de la bdd ou bien à la programmation du code, si je dois gérér cela avec des classes d'objets reliées entre elles ou bien des tables relationnelles.

Existe-t-il des méthodes ou bien ce n'est que l'usage qui me permettra de judicieusement choisir l'outil le plus approprié à chaque problème ?

[pascalbuguet]

bonjour cipic,
les deux :
un peu de théorie (pas trop pour l'instant) éclaire la pratique et vice-versa.
Pour la théorie pure sur les BDR (bases de données relationnelles) il y a l'algèbre relationnelle et mr CODD. Aucun intérêt pour l'instant.
Pour la théorie-pratique il y a la méthode MERISE (côté données). C'est franco-français. Ca date (comme le modèle relationnel d'ailleurs; tout cela vient des années 70) mais ça a fait ses preuves. C'est encore très utilisé dans les grands comptes.
J'ai vu récemment que 2 livres de mr Deviné, je crois, sont téléchargeables gratuitement sur le NET. Je ne les ai pas lus donc je ne peut rien dire sur le contenu mais l'auteur semble bon. Il y a un des ouvrages qui recense 60 cas pratiques. Ce doit être une mine.
Moi j'ai pratiqué les Tardieu, Coletti, ..., Matheron mais ça date, ça aussi.
Matheron était prof et donc très didactique, ça aide. Il proposait en outre une démarche, ce qui manque dans l'exposé des méthodes.
A l'heure actuelle c'est plutôt la méthode UML qui est utilisée. C'est OO (Orientée Objet).
MySQL, MSS, Oracle ... sont R pas OO.
PHP, Java, .NET, ... sont OO.
Donc il faut fréquenter les 2.
Pour revenir à votre problématique, si vous avez trouvé un outil qui vous convient et accélère votre développement, utilisez-le.
Mais puisque vous êtes curieux d'apprendre allez aussi vers la modélisation.
Pour terminer, provisoirement ?, entre l'usage et la théorie; si vous allez vous promener vers les Design-Pattern vous trouverez une définition du style (je raccourcis):
"Modèle éprouvé par la pratique". Mais bon il y a bien quelqu'un qui s'est penché sur la question, sur la pratique, a fait oeuvre d'abstraction, et nous a pondu un modèle.

Enfin : dans la BD ? hors la BD ?
ne mettez dans la BD que ce que votre SGBDR est capable de gérer efficacement. Un exemple limite : des images; un SGBDR est incapable de gérer efficacement une image. Donc autant la laisser "dehors" et ne stocker de son "adresse". C'est peut-être ce que vous propose votre outil.
Bon travail et bonne soirée

[fsmrel]

Bonsoir,


A cipic,

Pour répondre à votre question :

« La gestion des langues doit-elle être prise en compte au niveau conceptuel ? »

Dans mon premier message, je vous ai suggéré une partie de MCD (Modèle Conceptuel de Données), montrant qu’il était très simple de modéliser l’expression d’un texte donné dans une langue donnée en relation avec un événement donné.

A propos des réponses que j’ai faites à pascalbuguet, ne cherchez pas à suivre. Il s’agissait de montrer que l’exemple au format tabulaire que je vous ai proposé est dépourvu de redondance, et de lui signifier que ses considérations sur ce qu’on appelle la 2NF étaient hors de propos et que ses affirmations sur la performance de que l’on appelle la jointure n’ont aucun fondement.

Bon courage à vous

[fsmrel]

Bonsoir,


A pascalbuguet :

Pour reprendre vos termes, vous avez peut-être l’habitude de « chipoter », moi pas.

Quant aux « considérations » sur la 4NF et la 5NF, vous avez pris l’initiative d’invoquer la 2NF : vous n’auriez pas dû, puisque, — outre le fait que cipic ne connaît pas le sujet et on ne saurait lui en vouloir —, si vous le faites, automatiquement les autres formes normales suivent. Cela dit, vous prétendez que la 4NF et la 5NF sont peu appliquées : dites plutôt que vous ne les maîtrisez pas, et tant pis pour les anomalies inhérentes à leur non respect.

Quand vous écrivez :

« citic (sic) veut savoir s'il doit créer une table "lexique" ou plusieurs. Je lui en recommande une »

vous auriez pu être plus explicite, car au final chaque phrase devrait en toute logique hébergée par une table telle que celle j’ai proposée (table Presenter), sachant par ailleurs que l’entité-type Langue que j’ai fait figurer dans le rudiment de MCD donnera lieu à une table Langue.
Pour nous assurer que nous parlons de la même chose, je vous suggère de fournir à votre tour une ébauche de MCD à cipic. Rien, de tel qu’un bon dessin plutôt que les énoncés amphibologiques correspondants, en langue vernaculaire.

Un administrateur vous le dira, la tête de lecture se promène plus sur plusieurs clusters.

Je suis administrateur. Vous n’avez pas lu mon message précédent, dans lequel j’ai écrit : « Mais mon langage de DBA de terrain vous déroutera peut-être ». « DBA » veut dire « Database Administrator », en français « Administrateur des bases de données ».
Ne vous en faites donc pas pour les clusters. Un DBA de production sait répartir les tables sur les disques, de manière à ce que la parallélisation des I/O soit effective (Input/Outut = Entrée/Sortie= accès disque en lecture/écriture).

Par ailleurs pour le coût des jointures. Vous avez raison sur certains points : en pratique le SGBDR, le disque ... fera la différente.

Red herring. Les facteurs principaux sont en réalité les suivants et se situent à des niveaux différents : La façon dont les requêtes sont écrites, ainsi que la mise en oeuvre pertinente des index. En effet, même avec le meilleur SGBD du monde et les disques les plus rapides, si vous manipulez des tables comportant des millions de lignes, une requête mal écrite, peut consommer des millions de secondes avant de fournir un résultat. Pour avoir aidé des bataillons de développeurs angoissés à régler ce genre de problèmes, je sais de quoi je parle. Même chose si les « bons » index sont absents. Un bon coup d’œil valant mieux qu’une mauvaise impasse, l’utilisation de l’instruction EXPLAIN PLAN (ou équivalent, suivant le SGBD) s’impose.

Ce n'ai pour rien qu'à une époque SYBASE a pris de l'avance sur les autres 3 autres tigres (Oracle, DB2, Informix) en créant des semi-jointures.

C’était en quelle année ? Qu’entendez-vous par « créer des semi-jointures » ?
J’ai quand même regardé la documentation de Sybase à la rubrique Semijoin : si cela correspond à ce dont vous parlez, je n’ai rien vu d’original. L’algorithme présenté est tout à fait basique et était déjà bien sûr utilisé il y a 25 ans par DB2 (pour les autres SGBD je n’en sais rien). En langage de DBA, il s’agit d’un banal NESTED LOOP de l’OUTER TABLE (table titles) et d’un balayage limité à l’index utilisé par la clé étrangère {titleid} figurant dans l’autre table (titleauthor). Il n'y a vraiment pas là de quoi fouetter un chat.

Par ailleurs à une certaine époque Oracle (qui peut rester notre référence) fournissait des équations sur les calculs d'accès.

Tout d’abord, le professeur Serge Miranda a qualifié, à juste raison, Oracle de fils illégitime de System R (Comprendre et concevoir les bases de données relationnelles, page 110), et ma référence personnelle reste le fils légitime, à savoir DB2.

Maintenant, merci de préciser ce que vous entendez par « équations sur les calculs d'accès » et la date à laquelle Oracle a proposé cette possibilité. Si vous faites référence à l’instruction EXPLAIN PLAN, sachez que celle-ci existe dans DB2 depuis 1986 (release 1.2) et que sans elle, il est hors de question d’utiliser un SGBD en production quand le volume des données est conséquent (c’est du reste pourquoi j’ai refusé d’utiliser en production DB2 dans sa version 1.1, l’instruction EXPLAIN PLAN en étant absente). Au fil des ans, les autres SGBD s’y sont manifestement mis.

Une jointure est plus coûteuse qu'un select sur une seule table dénormalisée en FN2.

Non, non et non. Vous répétez une légende bien connue depuis des lustres et qui a la vie dure. Au fait, je vous avais demandé de me fournir votre définition de la 2NF, mais vous n’en avez rien fait.

Cela dit, prenez l’exemple de la table Reprendre que j’ai proposée dans mon premier message.

Si je vous suis, pour éviter une jointure du genre :

Code SQL :

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

1
2
3
4
 
Select  x.Texte, y.LangueNom, z.EvenementLibelle 
From    Presenter As x NATURAL JOIN Langue As y NATURAL JOIN Evenement As z
WHERE   y.LangueId = ...  AND  z.EvenementId = ...

alors vous préconisez de dénormaliser la table Presenter pour qu’elle ressemble à ceci (clé primaire soulignée) :

Presenter (EvenementId, LangueId, Texte, LangueNom, EvenementLibelle)

En conséquence de quoi, l’absence de jointure est au bénéfice d’une requête mono-table :

Code SQL :

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

1
2
3
4
 
Select  Texte, LangueNom, EvenementLibelle  
From    Presenter 
WHERE   LangueId = ...  AND  EvenementId = ...

Comme la table Langue sera d’une taille ridicule, elle résidera en mémoire et le gain résultant du viol de la 2NF sera égal à zéro. Autant ne pas dupliquer l’attribut LangueNom et effectuer la jointure. Reste le cas de la table Evenement : la jointure représente un surcoût de l’ordre de 3 à 4 I/O (entrées/sorties) à quelques millisecondes chacune, c'est-à-dire peu de chose.

Mais il faut voir plus loin que le bout de son nez. Déjà :

1) Quand vous changez une valeur de l’attribut EvenementLibelle dans une ligne de la table Evenement, alors il faut aussi modifier en conséquence toutes les lignes concernées de la table Presenter, redondance oblige, et cette fois-ci il y aura des paquets d’I/O, sans parler de la cohérence des données qui a toutes les chances d’être mise à mal. Cela vaut également si vous changez des valeurs de l’attribut LangueNom dans la table Langue.

2) La taille d’une ligne de la table Presenter s’accroît plus que significativement. En conséquence, chaque page physique contiendra moins d’enregistrements, d'où augmentation du nombre de pages (ce qui pénalise les traitements de type batch), et une obésité mal venue, même chose pour la hauteur (nombre de niveaux) des index. Ce que vous aurez gagné d’un côté en I/O sera perdu de l’autre. Et n’oubliez pas les autres effets secondaires : par exemple, les tâches de service (sauvegardes, réorganisations, etc.) seront pénalisées par la surcharge pondérale des tables, tout cela à cause d’un viol de la 2NF, alors qu’autrement, ces tâches peuvent être effectuées en parallèle, d’où un temps elapse bien meilleur. Et j’en passe (fichiers logs, opérations de rollback, ...)

Si pour vous « Une jointure est plus coûteuse qu'un select sur une seule table dénormalisée en FN2 », argumentez et prouvez, sans oublier de tenir compte des effets secondaires.

En réalité, seule une campagne pertinente de prototypage des performances permet de déterminer la performance des applications. Pour avoir prototypé pendant des centaines d’heures dans diverses très grosses entreprises, j’ai pu convaincre mes collègues DBA que le viol de la 2NF avait autant d’effet qu’un du cautère sur une jambe de bois. Si une application se traîne, il faut en chercher les causes ailleurs. La 2NF a vraiment bon dos. En 25 ans et des milliers de tables expertisées, j’ai trouvé un seul cas où le viol de la 2NF s’imposait (suite à un choix de modélisation critiquable a posteriori).

[Une jointure est plus coûteuse qu'un select sur une seule table dénormalisée en FN2. Un administrateur vous le dira, la tête de lecture se promène plus sur plusieurs clusters.]
Mr CODD (in english) et mr Gardarin (en français, un maître en la matière à Jussieu à l'époque aussi) vous le diront.

Pour avoir déjeuné avec lui, je confirme que le Dr. Codd (1923-2003) s’exprimait de préférence en anglais (et qu’il avait horreur du café français). Comme notre génial inventeur travaillait exclusivement au niveau de la logique formelle, les promenades des têtes de lecture ne le concernaient évidemment pas. Mais la 2NF, oui, puisqu’il l’inventa en 1971 (ainsi que la 3NF) : je vous renvoie à son article Further Normalization of the Data Base Relational Model, dans lequel il ne parle que des bienfaits de la normalisation sans évoquer le moins du monde l’aspect performance. Quant à Georges Gardarin (avec qui j’ai aussi eu le plaisir de déjeuner et d’évoquer plutôt le cyclotourisme en Auvergne), il écrivit en compagnie de Patrick Valduriez dans Relational Databases and Knowledge Bases, page 137 : « Denormalization is necessary to avoid costly join; however, too much denormalization tends to data redundancy... » Je n’ai pas discuté de ce sujet avec lui et je le regrette, mais je pense que l’avis du DBA l’aurait incité à être plus mesuré quant au coût des jointures.

Les exemples de dénormalisation en FN2 ne manquent pas.

C’est sûr, et mon rôle fut (trop) souvent de corriger le tir chez mes clients.

il doit y avoir d'autres lieux pour nous "amuser"

1) Non. Vous êtes sur le forum où l’on traite de la structure des données au sens relationnel du terme et donc de la normalisation des tables. C’et un sujet sérieux et plutôt méconnu.

[pascalbuguet]

bonjour,

Eh bien justement utilisez à bon escient Explain et vous lirez que le résultat d'une jointure en termes de lignes (rows) est nécessairement supérieur au résultat donné par la même commande EXPLAIN sur n'importe quelle requête mono-table.
Mais cela ne prouve pas tout.
Faites un calcul en millisecondes (dans un de vos envois vous écriviez qq chose du style "une jointure s'effectue en quelques millisecondes" )
Cela ne veut rien dire.
Sur quelle plate-forme. En local? Sur un serveur distant? En réparti ?
Bien sûr qu'un SELECT mono-table sur une plate-forme rapide est plus rapide qu'une jointure sur une plate-forme lente.
Mais sur la même plate-forme c'est évident.
Faites des tests et vous verrez!
Les résultats sont probants. Le rapport peut aller de 1 à 4.

Et puis c'est génial vous citez en anglais la thèse que je défends

Relational Databases and Knowledge Bases, page 137 : « Denormalization is necessary to avoid costly join; however, too much denormalization tends to data redundancy... »

Ben oui, une dénormalisation risque de créer de malencontreuses redondances ... mais elles sont moins coûteuses.

Bonne soirée.

[fsmrel]

Bonjour,

utilisez à bon escient Explain et vous lirez que le résultat d'une jointure en termes de lignes (rows) est nécessairement supérieur au résultat donné par la même commande EXPLAIN sur n'importe quelle requête mono-table.

Rassurez-vous, pendant 20 ans j’ai utilisé l’instruction EXPLAIN des milliers de fois, dans des contextes de production où l’on ne plaisante pas avec la validité des données et la performance des applications. Cela dit, en vertu du théorème de Heath le nombre de lignes produites à partir d’une table T (ne respectant pas la 2NF, ou la 3NF ou la BCNF) est strictement égal au nombre de lignes produites par la jointure des tables T1 et T2 après normalisation de T.

Faites un calcul en millisecondes (dans un de vos envois vous écriviez qq chose du style "une jointure s'effectue en quelques millisecondes" )
Cela ne veut rien dire.
Sur quelle plate-forme. En local? Sur un serveur distant? En réparti ?

Tout d’abord, je vous ai déjà dit que, je cite : « ma référence personnelle reste le fils légitime, à savoir DB2 ». Pour être plus précis, il s’agit de DB2 for z/OS.
Par ailleurs, il est évident que pour comparer des choses comparables, les tables en jeu doivent être sur un même serveur. Pour reprendre les exemples que je vous ai fournis :

Code SQL :

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

1
2
3
4
 
SELECT  x.Texte, y.LangueNom, z.EvenementLibelle 
FROM    Presenter AS x NATURAL JOIN Langue AS y NATURAL JOIN Evenement AS z
WHERE   y.LangueId = ...  AND  z.EvenementId = ...

Code SQL :

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

1
2
3
4
 
SELECT  Texte, LangueNom, EvenementLibelle  
FROM    Presenter 
WHERE   LangueId = ...  AND  EvenementId = ...

J’ai déjà expliqué que le surcoût de la jointure avec la table Langue est nul, puisque vu la taille de celle-ci elle reste en mémoire. Pour s’en assurer, il suffit de consulter les comptes-rendus de production en fin de journée.

Ensuite, je n’ai pas écrit « qq chose du style « une jointure s'effectue en quelques millisecondes » » mais « la jointure représente un surcoût de l’ordre de 3 à 4 I/O (entrées/sorties) à quelques millisecondes chacune ». Merci d’éviter les à-peu-près dans vos citations.

Supposons que la table Evenement comporte un million de lignes et la table Langue quinze lignes. Si chaque événement fait l’objet d’un texte dans chaque langue, la table Presenter comportera quinze millions de lignes.

La table Presenter fait l’objet d’un index « primaire » de quinze millions de couples (EvenementId, LangueId). Selon les algorithmes de DB2, la hauteur de l’index est égale à 4 (quatre niveaux d’index). Comme (avec DB2) la racine de l’index réside en mémoire, le nombre d’I/O index pour accéder à la page physique contenant l’unique ligne cible est égal à 3. La lecture de cette ligne nécessite à son tour un I/O. Le nombre d’I/O total pour traiter la deuxième requête est donc égal à 4. A 10 millisecondes l’I/O, cela représente 40 millisecondes (Il est évident qu’on suppose que la page cible n’est pas déjà présente en mémoire).

Prenons maintenant le cas de la 1re requête. Au coût précédent, il faut ajouter le coût pour récupérer le nom de la langue ainsi que le libellé de l’événement. Comme je l’ai déjà écrit, l’accès à la table Langue compte pour zéro (au moins avec DB2). Quant à l’accès à la table Evenement, toujours selon les algorithmes de DB2, la hauteur de l’index est égale à 3. Comme je l’ai dit précédemment, la racine de l’index réside en mémoire, donc le nombre d’I/O index pour accéder à la page physique contenant l’unique ligne cible est égal à 2. La lecture de la ligne contenant le libellé de l’événement nécessite un I/O. Le nombre d’I/O total pour récupérer le libellé est égal à 3. A 10 millisecondes l’I/O, cela représente 30 millisecondes (Il est évident qu’on suppose que la page cible n’est pas déjà présente en mémoire). Si dans une journée il y a 10000 exécutions de la requête, le surcoût I/O serait de 5 minutes, mais en réalité, DB2 trouvera le plus souvent en mémoire le résultat qu’il cherche. Là encore, il faudra éplucher les comptes-rendus de production pour connaître les chiffres exacts.

En tout état de cause, il n’y a pas à balancer entre respecter la 2NF et risquer tous les dangers (dont j’ai fait mention de certains) à ne pas le faire.

Et puis c'est génial vous citez en anglais la thèse que je défends

A ceci près que vous avez sorti la citation de son contexte en passant sous silence la partie la plus importante de ce que j’ai écrit, à savoir que si l’auteur avait pris l’avis du DBA, cela l’aurait incité à être plus mesuré au sujet du coût des jointures.

une dénormalisation risque de créer de malencontreuses redondances ... mais elles sont moins coûteuses.

Et tant pis si les données deviennent incohérentes, tant pis si la performance des mises à jour et celle des tâches de service se dégradent, etc. etc. Ces choses-là n'ont pas à être prises en compte en production, n'est-ce pas ?