Je construis une application sociale, qui suit / suivant le concept similaire à Twitter.
à partir d'un point de vue de la performance pour trouver le notes d'adeptes et les utilisateurs suivants, il est-il préférable de maintenir une table séparée pour les chefs? ou juste faire une requête de compte à chaque fois?
De même, j'ai une sorte de fonctionnalité d'enquête dans laquelle les gens peuvent voter, les gens ne peuvent voter que oui ou non, je stocke maintenant les votes dans une table séparée. Et j'ai besoin de montrer une liste d'enquêtes sans participants, non de oui et de non de non sur ma page d'accueil.
Semblable à la page d'accueil Stackoverflow (où ils affichent le nombre de votes, réponses et vues).
3 Réponses :
Ceci, comme la plupart des choses, dépend des modèles d'accès, c'est-à-dire que votre système sera utilisé. Si la mise à jour sera votre bouteille d'étranglement principal, vous ne devez pas inciter une surcharge supplémentaire en devant maintenir un compteur. Si d'autre part, lorsque vous accédez à des données dont le comptage vous permettra de vous préparez un temps considérable ou qu'il ne serait tout simplement pas possible de compter à chaque fois, vous devriez la précaulucquer.
En tant que directive générale, N'ajoutez pas de tableaux, comme la table de comptage séparée que vous proposez, qui sont là uniquement pour des optimisations de performances avant de mesurer la performance pour être un problème. Avoir une table de comptage séparé rompt la normalisation (comme tout type de mise en cache, car les données sont maintenant répliquées à deux endroits) et rendront le code plus compliqué, il ne faut donc pas être fait simplement parce que le compte pourrait être nécessaire.
(Tout ce qui dit, certaines bases de données prennent en charge Vues matérialisées / requêtes matérialisées qui vous permettent de facilement Faites ce genre de mise en cache de manière transparente à l'arrière-plan. Ces tables matérialisées sont mises à jour par la base de données. Le code de programme n'a donc pas à s'inquiéter à ce sujet et, en fonction de la sophistication de l'optimiseur de requêtes, peut être utilisé pour optimiser une requête de manière transparente .)
Merci Allagranti, pour le vote, je stocke également des dossiers individuels. J'ai des sondages et des voter. Donc, ma page d'accueil montre la liste des enquêtes avec le texte de l'enquête, le nombre de participants, le nombre de cas et non. Je dois donc faire une jointure extérieure entre l'enquête et la table de vote (en supposant que notre table vote augmentera sur la période de temps). Alors, pensez-vous que c'est bien de faire de l'extérieur avec la table de vote?
@MRBond: Pour quelques milliers d'enquêtes, je ne vois pas de problème. C'est toujours une question de taille. Et vous pouvez également mettre en cache la surveillance individuelle du serveur d'applications si nécessaire (ne communiquez donc même pas avec le serveur pour les 100 enquêtes les plus demandées). Mais encore une fois, sauf si vous savez que ce sera un problème, je ne l'accordais pas prématurément. Si vous le voyez devenir un problème, vous devriez être capable de réagir dans le temps, car ce n'est pas un changement de conception majeur (et parce que vous n'avez pas optimisé prématurément, il est plus facile d'adapter, aussi).
Cela dépend.
Si vous avez de nombreux utilisateurs, le nombre peut être assez long et charger de grandes parties de la table / index en mémoire.
Si vous faites un triger, vous perdez un peu de temps dans le processus de vidange, chaque action suivante déclenchée sera une lotlle plus lente.
Un mélange entre les deux, l'alimentation asynchrone d'une table statistique sur les adeptes peut vous donner les meilleurs résultats (des opérations d'écriture rapide, extrêmement rapides lors de la lecture).
Alternativement, vous pouvez utiliser deux conteneurs de données: