Joindre des requêtes et quand c'est trop

Question

Je trouve que j'utilise beaucoup de requêtes de jointure, en particulier pour obtenir des statistiques sur les opérations des utilisateurs à partir de ma base de données. Les requêtes de ce genre ne sont pas rares:

from io in db._Owners where io.tenantId == tenantId 
    join i in db._Instances on io.instanceId equals i.instanceId 
    join m in db._Machines on i.machineId equals m.machineId 
    select ... 

Mon application est toujours pas actif, donc je n'ai aucun moyen de juger si ces requêtes seront prohibitifs sur dans la vie réelle. Ma requête:

1. Y a-t-il une limite à trop de «jointures»? Est-ce que cela peut être décrit sans avoir des statistiques de fonctionnement réelles?
2. Quelles sont mes alternatives? Par exemple, est-il préférable de créer simplement des tables supplémentaires pour contenir des statistiques que je mets à jour au fur et à mesure, plutôt que de rassembler différentes sources de tables chaque fois que je veux des statistiques?

Answer 1

Si vous n'avez pas d'informations sur les performances, n'optimisez pas.

L'optimisation prématurée est la racine de tous les maux.

1) Je ne pense pas que vous atteindrez jamais la "limite". 2) Ceci s'appelle la dénormalisation, la dénormalisation prématurée est juste un effort gaspillé si vous ne savez pas si un problème existe. Je dirais que votre requête semble assez normale.

Answer 2

1) Y at-il une limite quand faire trop de « joint » est trop

Non, le nombre de jointures n'est pas un problème tant que la structure des données dans chaque tableau, la présence et l'utilisation des index et ce qui doit être fait pour obtenir des données.

Les données normalisées sont généralement un objectif principal dans la conception de base de données relationnelle. Vous considérez généralement la dénormalisation comme un moyen d'optimiser les requêtes uniquement si nécessaire en raison de l'effort supplémentaire requis pour maintenir la cohérence des données. Si vous êtes vraiment concerné, postez votre modèle de données ERD (tables de base de données &) et la base de données que vous utilisez pour le projet (car toutes les bases de données ne sont pas identiques).

Answer 3

À moins d'avoir un trafic très élevé et que les index soient correctement définis, etc., vous ne devriez pas avoir de problèmes. Pour les rapports/analyses, certains endroits créeront un data warehouse qui dans sa forme la plus basique est une copie [partiellement] dénormalisée de votre base de données principale. Ils sont plus faciles à signaler car une table contient généralement la plupart, sinon la totalité, des données nécessaires dans un rapport. Ils peuvent aussi être beaucoup plus rapides à lire car vous n'avez pas à vous joindre autant. Cependant, ils nécessiteront plus d'espace disque (données dupliquées). Si les écritures sont autorisées, elles seront plus lentes (vous devrez mettre à jour toutes les données dupliquées) et vous aurez le problème de conserver la cohérence de ces données dupliquées. En d'autres termes, à moins que vous ne fassiez que des rapports (ou un accès en lecture seule), conservez les jointures.