Puis-je utiliser un compteur dans une base de données Many-to-Many pour réduire les recherches?

Question

J'essaie de trouver le moyen le plus rapide d'accéder aux données stockées dans un objet de jonction. L'exemple ci-dessous est analogue à mon problème, mais avec un contexte différent, parce que l'ensemble de données auquel j'ai affaire est quelque peu inintéressant dans ses relations. Nous avons 3 classes: User, Product et Rating. L'utilisateur a une relation many-to-many à Product avec Rating comme classe de jonction/'through'.

L'objet Rating stocke les réponses à plusieurs questions qui sont notes entières sur une échelle de 1-5 (questions Exemple: comment convivial Comment est la qualité du Product, comment est la valeur de la Product, est Product). Pour simplifier assumer tous les User tous les Product qu'ils achètent.

est le calcul maintenant ici, je veux effectuer: Pour une User, calculer la note moyenne de tous les Product s ils ont acheté (c'est, la note moyenne de tous les autres Users, l'un qui sera de cette User lui-même). Ensuite, nous pouvons dire à l'utilisateur "En moyenne, vous achetez des produits classés 3/5 pour la valeur par tous les clients qui ont acheté ce produit".

La méthode simple et lente consiste simplement à parcourir tous les objets de révision d'un utilisateur. Si nous supposons que chaque utilisateur a acheté un petit nombre de produits (< 100), et que chaque produit a n valeurs nominales, c'est O (100n) = O (n).

Cependant, je pourrais aussi faire ce qui suit: Dans la classe Product, gardez un compteur du nombre de Rating s qui a choisi chaque numéro (par exemple le nombre de User noté ce produit 3/5 de la valeur). Si vous incrémentez ce compteur à chaque fois qu'un Product est évalué, le calcul de la moyenne pour un Product donné nécessite simplement de vérifier les 5 compteurs pour chaque critère .

Est-ce une technique valide? Est-il couramment employé/y a-t-il un nom? Cela me semble intuitif, mais je ne connais pas assez les bases de données pour savoir s'il y a un défaut fondamental ou non.

Answer 1

Ceci est normal. C'est en fin de compte la mise en cache: encoder l'état de manière redondante pour bénéficier de certains modes d'utilisation au détriment des autres. Bien sûr, c'est aussi une complexification. Le fait que la structure de données du SGBDR soit en relation ne signifie pas que vous ne pouvez pas réorganiser votre état de codage à partir d'une forme simple. Par exemple dénormalisation.

(Parfois, les conceptions redondantes (dont la vôtre) sont appelées «dénormalisées» lorsqu'elles ne résultent pas d'une dénormalisation et que la redondance n'est pas causée par la dénormalisation ou par la normalisation Cross Table Dependency/Constraint in SQL Database comme impliquant une normalisation sans préserver IFD (dépendances fonctionnelles). Commencez avec une table avec id & autres colonnes, leur ratings (une relation) d'un utilisateur & son counter. Ensuite ratings détermine fonctionnellement counter depuis counter = select count(*) from ratings. Décomposer à user etc + counter, c'est à dire le tableau User, et user + ratings, qui se dissocie au tableau Rating.)

---

Avez-vous une suggestion à le meilleur terme à utiliser lors de googler ce

Un commentaire fréquent par moi: Google beaucoup phrasés clairs, & concis spécifiques de votre question/problème/goal/desiderata avec différents sous-ensembles de termes & comme vous pouvez les découvrir avec & sans vos noms spécifiques (de variables/databases/tables/columns/contraintes/etc). Par exemple, quand puis-je stocker un (somme OU total) de manière redondante dans une base de données? Le phrasé humain, pas seulement les mots-clés, semble aider. Votre meilleur pari peut être le long de l'optimisation des conceptions de base de données SQL pour la performance. Il y a des livres entiers ('amazon isbn'), certains en ligne ('pdf'). (Mais peut-être surtout des requêtes). Étudiez les techniques relatives à l'entreposage, car une base de données OLTP agit comme un tampon d'entrée dans une base de données OLAP et utilise SQL avec des données volumineuses. Post-scriptum par exemple.

PS Mon appel à cette «mise en cache» (le tag caching) est (plutôt typique de moi) plutôt abstrait, au point où il y a des blagues sérieuses que tout cache dans CS. (Googling ... "Il ya seulement deux problèmes difficiles en informatique: invalidation de cache et nommer les choses." - Phil Karlton.) (Bienvenue aux deux.)