Discussion :

[sebastien.cas]

Bonjour à tous,

J'ai 3 tables modélisés.
Chacune des trois tables ont des données en commun.

Je me suis donc dis, je vais créer une table qui contient les données communes, puis 3 autres tables qui ne contiennent que les données spécifiques.

Bref un héritage.

Mais parlons optimisation, performance ...

Est il préférable d'avoir un héritage (jointure dans toutes mes requêtes...) ou alors de n'avoir que 3 tables (sans héritage donc duplicata des données communes dans chaque table).

Merci pour vos futurs conseils

[Le Pharaon]

Mais parlons optimisation, performance ...

Ces deux critères sont à mon avis contradictoires dans cette situation.
Héritage : Optimisation OUI, performance Non.
Pas d'héritage : Optimisation NON, performance peut-être.

Plus il y'a de jointures moins il y'a de performance dans le traitement des requêtes.

[sebastien.cas]

Justement !

Qu'est il préférable de faire...
On privilégie l'héritage ou pas...

La base de données sera volumineuse, et le nombre de requête très important...

[Fleur-Anne.Blain]

Lu,

Héritage ou non? cela dépend...Tu préfères avoir un modèle qui est normé et donc de qualité ou bien privilégier les performances???
Tu as dit que la base de données était volumineuse mais ton problème ne concerne que trois tables c ca??

C'est un choix que tu dois faire...la performance varie tant que ça pour ne pas faire d'héritage?

[sebastien.cas]

Les trois tables, c'est pour illustrer mes propos.

Pour les perfs, je sais pas trop si ca varie tant que ca justement...
C'est ca mon problème.

[Nip]

C'est un choix que tu dois faire...la performance varie tant que ça pour ne pas faire d'héritage?

Juste pour repondre a cette question: nous sommes dans le cadre de SGBDRELATIONNELLES, cad ce sont des bases de donnees faites pour les jointures et les rendre extremement confortables et rapides; c'est pas 3 jointures dans un select qui vont faire baisser les perfs.

[sebastien.cas]

Ok !
merci pour ces précisions...

[Fleur-Anne.Blain]

Personnellement, j'ai eu ton problème sous oracle 8 mais je n'irais pas non plus généraliser...(aux autres SGBD).J'ai préféré avoirun modèle normé et donc plus clair pour tout le monde car au niveau performance, la différence était dérisoire. Mais de la base je devais utiliser au maximum 4 ou 5 tables ( avec des jointures) et ce n'est peut-être pas ton cas.

[TheLeadingEdge]

Plus il y'a de jointures moins il y'a de performance dans le traitement des requêtes.

Ca c'est 1 légende colportée par les mauvais concepteurs et qui arrange bien les mauvais DBA
(... ou comment se faire plein de copains d'1 coup )

[Luc Orient]

Ca c'est 1 légende colportée par les mauvais concepteurs et qui arrange bien les mauvais DBA
(... ou comment se faire plein de copains d'1 coup )

+1
Les jointures correctement indexées sont très performantes.
Et elles représentent l'essence même du relationnel.
Voir aussi ce fil :
Rapidité d'une requête SQL

[pcaboche]

Est il préférable d'avoir un héritage (jointure dans toutes mes requêtes...) ou alors de n'avoir que 3 tables (sans héritage donc duplicata des données communes dans chaque table).

Si tu te poses la question, c'est que as très bien analysé le problème et que tu sauras adapter ta solution en fonction du besoin.

D'une manière générale, j'aurais tendance à penser que la solution de l'héritage est plus "propre" et plus souple.

Maintenant, si tous les éléments de la table de base (~classe abstraite) ont une taille fixe, alors les enregistrements de cette table auront eux aussi une taille fixe, ce qui accélère les recherches. Dans ce cas particulier, l'héritage peut se révéler plus performant. Cela prouve une chose: on ne peut rien généraliser !

La seule chose que l'on peut dire, c'est que dans une certaine mesure on tolère qu'un programme soit un peu moins performant si ça le rend plus clair et plus facile à maintenir. Le plus important, c'est de savoir quelle partie du programme il faut optimiser (ex: les portions de codes souvent appellés) et connaître le but de l'optimisation (vitesse? mémoire? problèmes d'échelle?).

[Nip]

Pour completer ce que je disais plus haut et confirmer les remarques de pcaboche, tout est une question de compromis: ce ne sont jamais les performances du SGBDR qui sont en cause mais la maniere dont ton application est concue. Les points critiques de performance sont toujours, ou presque, dus a des soucis de conception (et donc la plupart du temps tres difficiles a resoudre). Donc ne te demande pas si les jointures sont performantes ou non, mais plutot si tu adoptes la meilleure maniere de presenter tes donnees et d'y d'acceder, reflechi bien a la facon dont seront mappees tes tables. Si ton modele est correctement pense et concu, les "optimisations" seront minimes et les performances satisfaisantes des le depart.

[Le Pharaon]

+1
Les jointures correctement indexées sont très performantes.
Et elles représentent l'essence même du relationnel.
Voir aussi ce fil :

Et qu'est ce qui représente l'essence de la dénormalisation ?

Il est crucial de définir une structure normalisée complète d'une base de données avant d'en commencer la mise en œuvre. Une fois la mise en œuvre entamée, il est difficile d'effectuer des modifications de conception lorsqu'on découvre des incohérences logiques. Si le processus de normalisation assure la cohérence des données, il peut nuire aux performances. C'est pourquoi il arrive régulièrement qu'on dénormalise intentionnellement une base de données et qu'on traite les incohérences potentielles que cela peut entraîner à l'aide de contraintes, de règles ou de déclencheurs.

Source

Ca c'est 1 légende colportée par les mauvais concepteurs et qui arrange bien les mauvais DBA
(... ou comment se faire plein de copains d'1 coup )

Et c'est trop facile de renier des dires sans arguments à l'appui

[TheLeadingEdge]

Re,

La citation est au conditionnel.

il peut nuire aux performances.

On est loin de l'affirmation pure et simple qui consiste à dire que ds 100% des cas quand on normalise une base on dégrade ses performances

D'autre part je n'évoquais pas le débat ''modèle en FN vs modèle denormalisé''.
Je parle bien du rapport jointures/vitesse d'exécution d'une requête qui était le sujet du post auquel j'ai répondu.

Ma source c'est moi-même.
Je pense avoir pratiqué assez le sujet pour avoir un avis recevable sur la question.

Quant aux arguments, je veux bien admettre qu'en cherchant bien on puisse trouver des exemples ou (à résultat et volume de données égaux) des jointures supplémentaires ralentissent une requête. Mais je suis sur d'en trouver au moins autant qui montreront le contraire.

Pour conclure je continue de dire qu'il est faux d'affirmer que l'utilisation de jointures va à ts les coups ralentir 1 requete.

Mais je ne t'oblige pas à penser la meme chose que moi (tant que tu ne travailles pas pour moi ;-) )

A +

[Le Pharaon]

Je voudrais te faire savoir que chaque jointure a un coût, négligeable soit-il.

On est loin de l'affirmation pure et simple qui consiste à dire que ds 100% des cas quand on normalise une base on dégrade ses performances

Si c'est pour faire un jeu de mots tu as gagné, ce n'est pas mon point fort. Il me semble que nos avis ne sont pas très différents l'un de l'autre

Cordialement !

[Luc Orient]

Je voudrais te faire savoir que chaque jointure a un coût, négligeable soit-il ...

Certes, chaque jointure a un coût, mais chaque redondance de données a aussi un coût en ce qui concerne la mise à jour de ces dernières ....
Sans compter le risque d'incohérence des données dont le coût est là difficile à chiffrer ...

[pcaboche]

Je voudrais te faire savoir que chaque jointure a un coût, négligeable soit-il.

Ce qui a un coût important, ce sont aussi les GROUP BY.

<troll>
Oui les jointures ont un coût: elles nécessitent de trouver un ingénieur qui sache en faire et parfois ça devient rare...
</troll>

[Nanci]

Il faut distinguer le niveau conceptuel et le niveau relationnel.
Au niveau MCD, c'est une approche sémantique. Le problème posé correspond exactement à celui d'un héritage. Oui, il est indispensable de le modéliser comme tel.

Maintenant, au niveau MLD/MPD, se pose la question de comment le mettre en oeuvre sachant que les bases relationnelles ne le prennent pas directement en compte et qu'il faut trouver une solution de traduction.
Le choix de la "meilleure" solution dépend de plusieurs paramètres
- volume des attributs sur-type / sous-type
- existence de relations sur-types / sous-types
- modalités d'utilisation
Toutes ces considérations relèvent alors de choix d'optimisation et de performance