La raison invoquée par le créateur du système est que les jointures sont coûteuses en temps de traitement. Est-ce une idée fausse ? Est-ce parfois vrai, parfois faux ?
Ca c'est une légende...Sur une base bien conçue et utilisée ds des conditions normales les jointures ne devraient pas pénaliser.
Dans des conditions normales : ie Pas de requête de la mort façon BI.
Bien conçue : Les besoins ont été correctements exprimés et pris en compte, normalisée (of course) et ds laquelle on évite entr'autre les PK composée du nom par ex.
Un simple explain sur sur une requête qui extrait les produits d'un certain type parmi les 100 000 que contient une table devrait te convaincre qu'un full scan table est plus couteux que si tu fais 1 jointure avec une table ''type de produit'' qui va te réduire de 90% le volume des tuples à lire.
Enfin avoir un schéma non normalisé peut même augmenter le nombre de jointures et plomber le temps de dev. et les perfs.
Imagines une société de VPC qui as 1 table ''couts de transports'' de ce genre.
1 2 3 4 5 6
| transporteur, prix, destination
UPS, 25, Lyon
Colissimo, 35, Paris
Calberson, 35, Paris
x, 25, Lyon
y, 25, Marseille |
au lieu de 2 tables transporteur et destination.
Si un utilisateur veut connaitre le prix moyen de ttes les destinations tu es mal.
SELECT AVG(tarif) FROM ...
= 29 au lieu de 28,35 (arrondi).
Pour t'en sortir il faut faire une rq du genre
1 2 3 4 5 6 7
| SELECT AVG(tarif)
FROM
(
SELECT tarif
FROM Cout
GROUP BY destination, tarif
) AS Tmp; |
no comment
Partager