Discussion :

[remy67]

Bonjour,

La question peut sembler simple, mais je n'ai pas trouvé de réponse à proprement parler.

Dans le cadre d'un accès en production, est-il préférable de requêter sur des vues, ou utiliser des jointures (en l'espèce Postgresql avec requete web php).
Sachant que ma base est comme sqlpro les aime, avec beaucoup de tables et peu de colonnes, si je souhaite faire une requête complexe, je vais avoir pas mal de jointures.
Mais je préfère m'amuser avec des jointures que de perdre en performance...

Y'a-t-il un article qui aborde le sujet ?

Merci beaucoup

[CinePhil]

Votre vue aura probablement des jointures donc ça ne changera pas grand chose au niveau performances, si ce n'est que, peut-être, le plan d'exécution de la vue sera stocké en mémoire et ce sera ça de gagné dans l'exécution des requêtes.

Les vues permettent de faire abstraction du schéma de la BDD. À la limite, l'application n'a pas à connaître ce schéma. Elle a un objet métier qui a besoin de données situées dans plusieurs tables alors elle interroge une vue qui représente son objet métier.

[SQLpro]

Mais je préfère m'amuser avec des jointures que de perdre en performance...

Vous ne perdrez pas de performance si vous utilisez un bon SGBDR comme Oracle ou SQL Server en utilisant exclusivement des vues pour toutes vos requêtes...

En effet ces SGBDR disposent d'un optimiseur à la fois sémantique et statistique. L'optimiseur sémantique permet de simplifier des requêtes lorsque certaines opérations sont inutiles. Par exemple si vous avez fait une vue avec 5 jointures et que la requête finale n'en à besoin que de 4 parce que vous ne ramenez aucune information de la 6e table, alors cette branche de jointure sera ignorée et la plan de requête simplifié....

Évidemment, si vous êtes sur MySQmerde, il en va tout autrement !

Mieux : ne pas utiliser des vues risque de vous poser à des problématiques insolubles... Un seul exemple. Pour calculer le CA TTC d'une entreprise de vente, on peut au choix :

• faire le TOTAL HT par ligne, puis faire la somme par TVA et enfin appliquer les différents taux de TVA et sommer la résultat
• faire le total TTC par ligne, puis faire la somme

Ces deux requêtes sont valables et il y a de fortes chances qu'elle ne donne pas le même résultat; En effet les règles de calculs étant différentes, les arrondis ne se feront pas dans le même sens !
En fixant la règle par une vue et en obligeant à passer systématiquement par la vue on a l'assurance d’obtenir toujours le même résultat !
Si on laisse faire chaque développeur avec les tables, on aura autant de résultats et les comptables vont s'arracher les cheveux !

A +



A +

[remy67]

Merci pour vos réponses,
Je vais donc forcer l'utilisation des vues dans mon projet.

Y a-t-il des règles spécifiques concernant la création des vues ? Dans mes recherches, je n'ai pas vu de tuto ou remarques particulières concernant ce thème, à croire que cela est accessoire.


Pour ma défense concernant Postgresql, sans rentrer dans un débat technique, mon expérience étant de toute façon totalement insuffisante pour argumenter, quand je constate l'utilisation croissante des ORM, un concept auquel je n'adhère pas du tout, le tout associé à Mysql qui pour le coup est effectivement une blague. Sans être dans la vérité, j'essaie de m'en rapprocher le plus possible avec le peu de moyens que j'ai .

(J'ai également posé deux questions je ne sais pas si vous avez une alerte dans ces cas,
http://blog.developpez.com/exercices...n_de_personnes
http://blog.developpez.com/exercices..._d_une_adresse )

[SQLpro]

PostGreSQL est bien plus costaud que MySQL au niveau des vues. Néanmoins, il ne dispose pas de l'optimisation sémantique indispensable pour utiliser les vues de manière performante. Ce n'est pas très grave tant que vous n'avez pas de grandes antiquités de données et que vous faites attention à créer des vues pas trop génériques !

J'ai répondu a vos demandes sur le bogue des exos de modélisation.

A +

[remy67]

Merci beaucoup !!!
Votre réponse appelle une nouvelle question.

On parle souvent de la quantité de données, mais au final je n'ai jamais vu pour le moment une échelle de taille.

Une petite base 1 million de lignes ?
Une grosse base 10 millions ?

Question subsidiaire, comment compter ce nombre de lignes

- Somme total de l'ensemble des lignes des tables.

- Nombre de lignes de la table la plus grosse.

- Ou nombre de lignes via les jointures justement en lien avec ma question initiale.

Bonne journée

[SQLpro]

Le nombre de lignes d'une table est beaucoup moins important que le volumétrie d'une table ou d'une base.

100 millions de lignes d'une table d'une seule colonne de type INT représente à peu près 100 Mo... c'est à dire un petit volume par rapport à la RAM du serveur (quelques Go !)

A +