Ma question concerne la dénormalisation. Dans une base de données, quand devriez-vous stocker des données dérivées dans sa propre colonne, plutôt que de le calculer à chaque fois que vous en avez besoin?
Par exemple, dites que vous avez des utilisateurs qui obtiennent des upvotes pour leurs questions. Vous affichez la réputation d'un utilisateur sur leur profil. Lorsqu'un utilisateur est évoqué, devriez-vous incrémenter leur réputation ou si vous le calculez lorsque vous récupérez leur profil: p> Comment le processeur intensive est la requête pour obtenir la réputation d'un utilisateur être avant qu'il ne soit utile de garder une trace de cela progressivement avec sa propre colonne? P> Pour continuer notre exemple, supposons qu'un uppote ait un poids qui dépend du nombre de susvotes (non de la quantité de réputation). qui l'a lancé a. La requête de récupération de leur réputation explose soudainement: P> SELECT
User.id AS User_id,
SUM(UpvoteWeight.weight) AS reputation
FROM User
LEFT JOIN Question
ON User.id = Question.User_id
LEFT JOIN (
SELECT
Upvote.Question_id,
COUNT(Upvote2.id)+1 AS weight
FROM Upvote
LEFT JOIN User
ON Upvote.User_id = User.id
LEFT JOIN Question
ON User.id = Question.User_id
LEFT JOIN Upvote AS Upvote2
ON
Question.id = Upvote2.Question_id
AND Upvote2.date < Upvote.date
GROUP BY Upvote.id
) AS UpvoteWeight ON Question.id = UpvoteWeight.Question_id
GROUP BY User.id
3 Réponses :
Il n'y a vraiment pas de réponse claire car elle dépend beaucoup de facteurs comme le volume du site et la fréquence à laquelle vous affichez la réputation (c'est-à-dire uniquement sur leur page de profil ou à côté de chaque instance de leur nom d'utilisateur, partout) . La seule réponse réelle est "quand il devient trop lent"; En d'autres termes, vous auriez probablement besoin de tester les scénarios et d'obtenir des statistiques de perfromance réelles.
Personnellement, je me désordonnerais dans cette situation particulière et que vous disposez d'un déclencheur d'insertion sur la table UPVote ou d'une requête de mise à jour périodique qui met à jour la colonne de réputation dénotromalisée. Est-ce que vraiment la fin du monde est la repère de quelqu'un qui a dit "204" au lieu de "205" jusqu'à ce que la page se renseigne?
Comment intensive du processeur fait la requête pour obtenir la réputation d'un utilisateur doivent être avant qu'il serait utile de garder une trace de celui-ci progressivement avec sa propre colonne?
Il y a vraiment deux questions ici en guise d'un: (1) Est-ce que ce changement améliorer la performace et (2) Est-ce que l'amélioration des performances en vaut la peine ?
Quant à savoir si l'amélioration des performances, cela est essentiellement une analyse avantages / inconvénients standard.
Les avantages de la normalisation sont essentiellement deux fois:
plus facile l'intégrité des données
Aucun problème de re-calcul (par exemple, si les modifications de données sous-jacentes, les besoins de colonnes dérivées d'être re-calculée).
Si vous couvrez l'intégrité des données avec une solution (par exemple déclencheur, Sstored-proc uniquement les modifications de données avec révoquées perms changement de table directe, etc ...) avec vigueur mis en œuvre, alors cela devient un calcul simple de savoir si le coût de la vérification si les bons de changement de données source des données dérivées recalcul par rapport recalculant les données dérivées à chaque fois. (NOTE: Une autre approche pour maintenir l'intégrité des données est de forcer le recalcul des données dérivées dans les délais prévus, où les données peuvent se permettre d'être inexactes avec une certaine tolérance de temps StackExchange prend cette approche avec certains de ses chiffres.) .
Dans un scénario typique (beaucoup plus la récupération des données et beaucoup moins des modifications aux données sous-jacentes) les mathématiques assez évidemment des biais en faveur de la conservation des données dérivées de normalisées dans le tableau.
Dans certains cas rares où les données sous-jacentes changent encore très souvent les données dérivées ne sont pas récupérées que, souvent, faire qui pourrait être préjudiciable.
Maintenant, nous sommes sur la question beaucoup plus importante: Est-ce que l'amélioration des performances en vaut la peine ?
S'il vous plaît noter que, comme avec toutes les optimisations, la plus grande question est « est l'optimisation même pas la peine du tout? », Et en tant que tel est l'objet de deux considérations principales:
mesure de la différence de performance exacte et le profilage en général.
Contexte de cette optimisation spécifique dans la grande image de votre système.
par exemple. si la différence dans la requête performace - qui, comme toujours lors de l'optimisation doit d'abord être mesurée - est de 2% entre les données dérivées mises en cache et calculé un, la complexité du système supplémentaire dans la mise en œuvre de la colonne de cache de réputation ne peut pas être la peine en premier lieu. Mais ce que le seuil de soins par rapport à ne pas se soucier est autant que l'amélioration marginale dépend de la grande image de votre application. Si vous pouvez prendre des mesures pour améliorer les performances des requêtes 10% dans un endroit différent, concentré sur ce contre 2%. Si vous êtes Google et 2% supplémentaires de la performance de requête porte coût de 2 milliards de dollars en matériel supplémentaire pour le supporter, il doit être optimisé de toute façon.
Je voulais juste jeter un autre angle sur la préoccupation de l'intégrité des données que DVK couvert si bien dans la réponse ci-dessus. Pensez à si d'autres systèmes peuvent avoir besoin d'accéder à / calculer les données dérivées - même quelque chose d'aussi simple qu'un système de reporting. Si d'autres systèmes doivent utiliser la valeur dérivée ou mettre à jour la valeur UPVote, vous pouvez avoir des considérations supplémentaires sur la manière de réutiliser le code de calcul ou sur la manière de vous assurer que la valeur dérivée est constamment mise à jour, quel que soit le système change le système UPVOTE.