des conseils sur les attributs SQL précalculées

Question

Souvent, je traite avec des entités globales ou des parents qui ont des attributs dérivés de leurs membres constitutifs ou les enfants. Par exemple:

• Le byte_count et packet_count d'un objet est calculée à partir TcpConnection les mêmes attributs de ses deux objets TcpStream constitutifs, qui sont à leur tour calculée à partir de leurs objets TcpPacket constitutifs.

• Un objet Invoices pourrait avoir un total qui est essentiellement la somme () de son InvoiceLineItems constituant » des prix, avec un peu de fret, de réduction et de la taxe logique jeté.

Lorsque vous traitez avec des millions de paquets ou des millions de postes facturés (je veux!), Le calcul à la demande de ces attributs dérivés - soit dans une vue ou plus communément dans la logique de présentation comme des rapports ou des interfaces Web - est souvent beaucoup trop lent.

Comment décidez-vous, avant les problèmes de performances forcent la main, que ce soit à « promouvoir » les attributs dérivés aux champs précalculées?

Answer 1

Personnellement, je ne dénormaliser que des compromis forcer la main de performance (parce que la baisse de dénormalisations sont à mon humble avis trop drastique), mais vous pourriez aussi envisager:

1. Commodité : par exemple si deux applications clientes différentes veulent calculer les mêmes attributs dérivés, ils ont tous deux à coder les requêtes pour les calculer. Dénormalisation offre à la fois client applications l'attribut dérivé d'une manière plus simple.
2. Stabilité au fil du temps : par exemple si la formule de calcul d'un attribut dérivé est modifiable, dénormalisation vous permet de capturer et de stocker la valeur dérivée à un point dans le temps des calculs si l'avenir ne sera jamais se tromper
3. requêtes Simpler :. Complexifier la structure DB peut signifier votre requête de sélection est plus simple à la fin du client
4. Performance :. Sélectionner des requêtes sur des données dénormalisées peut être plus rapide

Ref: La base de données du programmeur: L'argument pour dénormalisation . Assurez-vous de lire aussi bien son article sur Honorer les valeurs dénormalisées correcte - sa recommandation est d'utiliser les déclencheurs. Cela nous amène à la maison le genre de dénormalisation de compromis exige.

Answer 2

En fait, vous ne le faites pas. Vous avez laissé les problèmes de performances forcer la main.

C'est la meilleure réponse parce que 99% du temps, vous devriez pas être pré-optimisation comme celui-ci, il vaut mieux que calco à la volée.

Cependant, il est assez fréquent pour les développeurs client applications à venir au côté serveur avec des idées préconçues erronées comme « calcul sur la demande de ... attributs dérivés ... - est souvent trop lent », et ce n'est pas vrai. ici la formulation correcte serait " rarement trop lent ".

En tant que tel, à moins que vous êtes un expert dans ce (un architecte de développement DB, etc.), vous ne devriez pas être dans l'optimisation prématurée engagez. Attendez jusqu'à ce qu'il soit évident qui doit être fixé, puis regarder pré-agrégation.

Answer 3

Comment les données en cours doivent être détermine la façon dont vous le mettre en œuvre, vraiment.

Je suppose que 2 états simples: courant ou non courant

.

• Current: vues indexées, stockées, déclencheurs procs pour maintenir des tables d'agrégation, etc
• Pas à jour: rapports instantanés de service, envoi de journaux / réplication, entrepôt de données, etc.

Cela dit, je développais contre la même quantité de données que je prod donc j'ai une certaine confiance dans le temps de réponse. Il est rarement surpris par les performances de votre code ...