Comment les vues fonctionnent-elles dans un DBM?

Question

Dites que j'ai deux tables comme celles-ci:

Employers (id, name, .... , deptId).
Depts(id, deptName, ...).

Mais ces données ne vont pas être modifiées si souvent et je veux qu'une requête comme celle-ci

SELECT name, deptName FROM Employers, Depts 
    WHERE deptId = Depts.id AND Employers.id="ID"

être aussi rapide que possible.

Deux solutions sont possibles:

• Dénormaliser le tableau:

  Malgré cela, avec cette solution, je vais perdre certains des grands avantages des "bases de données normalisées", mais ici, les performances sont indispensables.

• Créez une vue pour ces données Denormalize.

  Je maintiendrai les données normalisées et ( voici ma question ), les performances d'une requête sur cette vue seront plus rapides que sans cette vue.

Ou une autre façon de poser la même question, la vue est " interprétée " chaque fois que vous faites une requête dessus, ou comment fonctionnent les vues Stuff dans un DBA?.

Answer 1

En général, à moins que vous "matérialisiez" une vue, qui est une option dans certains logiciels tels que MS SQL Server, la vue est simplement traduite en requêtes sur les tables de base, et n'est donc pas plus rapide ni plus lente que l'original (moins le temps minuscule nécessaire pour traduire la requête , ce qui n’est rien comparé à l’exécution de la requête).

Comment savez-vous que vous avez des problèmes de performances? Le profilez-vous sous charge? Avez-vous vérifié que le goulot d'étranglement lié aux performances réside dans ces deux tables? Généralement, jusqu'à ce que vous obteniez des données concrètes, ne présumez pas que vous savez d'où viennent les problèmes de performance, et ne perdez pas de temps à optimiser jusqu'à ce que vous sachiez que vous optimisez le bon choix - 80% des problèmes de performance proviennent de 20 % du code.

Answer 2

Si Depts.ID est la clé primaire de cette table et que vous indexez le champ Employers.DeptID, cette requête doit rester très rapide, même pour des millions d'enregistrements.

La dénormalisation n’a aucun sens pour moi dans ce scénario.

De manière générale, les performances d'une vue seront presque identiques à celles obtenues lors de l'exécution de la requête elle-même. L’avantage d’une vue est simplement d’abréger cette requête afin que vous n’ayez pas à y penser.

Vous pouvez utiliser une vue matérialisée (ou un "instantané", comme certains le disent), mais vos données ne seront alors aussi récentes que votre dernière actualisation.

Answer 3

Dans un commentaire sur l'une des réponses, l'auteur de la question explique qu'il cherche un moyen de créer une vue matérialisée dans MySQL.

MySQL n’emballe pas le concept de la vue matérialisée dans un package intéressant comme les autres SGBD, mais il dispose de tous les outils nécessaires pour en créer un.

Ce que vous devez faire est le suivant:

1. Créez la matérialisation initiale du résultat de votre requête.
2. Créez un déclencheur lors de l'insertion dans la table des employeurs qui insère dans la table matérialisée toutes les lignes correspondant au nouvel employeur inséré.
3. Créez un déclencheur à la suppression dans la table des employeurs, qui supprime les lignes correspondantes de la table matérialisée.
4. Créez un déclencheur à la mise à jour dans la table des employeurs qui met à jour les lignes correspondantes dans la table matérialisée.
5. Idem pour la table des départements.

Cela peut fonctionner correctement si vos tables sous-jacentes ne sont pas fréquemment mises à jour. mais vous devez être conscient du coût supplémentaire des opérations de création / mise à jour / suppression une fois cette opération effectuée. Vous voudrez également vous assurer que certains administrateurs de base de données qui ne connaissent pas votre astuce ne migrent pas la base de données sans migrer les déclencheurs, le moment venu. Alors documentez-le bien.

Answer 4

Cela ressemble à une optimisation prématurée, à moins que vous ne sachiez que le problème est clair et présent.

MySQL ne matérialise pas les vues, elles ne sont pas plus rapides que les requêtes sur les tables de base. De plus, dans certains cas, ils sont plus lents car ils sont moins bien optimisés.

Mais les vues contiennent également "masquer". des informations fournies par les développeurs qui gèrent le code à l’avenir pour leur faire croire que la requête est moins complexe qu’elle ne l’est réellement.