Conception de base de données la plus efficace pour un blog (messages et commentaires)

Question

Quelle serait la meilleure façon de concevoir une base de données pour stocker des billets de blog et des commentaires? Je pense actuellement à une table pour les messages, et une autre pour les commentaires, chacun avec un ID de poste. Il me semble, cependant, parcourir une grande table de commentaires pour trouver ceux pour le poste concerné serait coûteux, et serait fait chaque fois qu'un article de blog est chargé (peut-être avec une certaine quantité de mise en cache).

Y a-t-il un meilleur moyen?

Answer 1

Il me semble, cependant, la pêche au chalut à travers une grande table de commentaires

Tous les fournisseurs de base de données d'accord avec vous.

Ils offrent des "index" pour limiter cela.

Answer 2

Chaque système de base de données que vous utiliseriez pour implémenter votre blog utilisera indexation. Cela signifie que, plutôt que de «parcourir une grande table», votre système de base de données conserve une liste séparée de commentaires et les messages auxquels ils sont associés, un peu comme l'index à la fin d'un livre. Cela permet au système de base de données de charger les commentaires associés à un message extrêmement rapidement, et je ne vois aucun problème avec votre conception proposée pour un blog de n'importe quelle taille. Les index sont couramment utilisés pour associer des tables avec des millions de lignes à d'autres tables avec des millions de lignes - vous devez avoir un blog exceptionnellement volumineux pour requérir la dénormalisation des commentaires, et encore, la mise en cache vous servira probablement mieux que dénormaliser la base de données.

Vous devrez définir un index sur votre table de commentaires et l'associer à n'importe quelle colonne contenant l'ID de message. La façon dont cela est fait dépend du système de base de données que vous utilisez.

Answer 3

pêche au chalut à travers une grande table de commentaires pour trouver ceux pour la

poste en question serait cher,

Un index est toujours là pour vous sauver! Premier indice sur postId et un autre de commentdate (desc)

Answer 4

essayer quelque chose comme ceci:

Blog 
BlogID  int auto number PK 
BlogName string 
... 

BlogPost 
BlogPostID int auto number PK 
BlogID  int FK to Blog.BlogID, index 
BlogContent string 
.... 

Comment 
CommentID  int auto number PK 
BlogPostID  int FK to BlogPost.BlogPostID, index 
ReplyToCommentID int FK to Comment.CommentID <<for comments on comments 
... 

Answer 5

D'accord, nous allons voir.

pêche au chalut à travers une grande table de commentaires pour trouver ceux pour le poste en question serait coûteuse

Pourquoi pensez-vous que ce serait cher? Parce que vous croyez peut-être qu'une recherche linéaire sera faite à chaque fois en prenant le temps O (n). Pour un milliard de commentaires, un milliard d'itérations sera fait.

Supposons maintenant qu'un arbre de recherche binaire est construit pour comment_ID. Pour rechercher un commentaire, vous avez besoin du temps de log (n) [base 2]. Donc, même pour 1 milliard de commentaires, seulement environ 32 itérations seront nécessaires.

Considérons maintenant un BST légèrement modifié, où chaque nœud contient k éléments au lieu de 1 (dans une liste) et a k + 1 nœuds enfants. Les mêmes propriétés de BST sont également suivies dans cette structure de données. Ce que nous avons ici s'appelle un arbre B. More reading: GeeksForGeeks - B Tree Introduction

Pour un arbre B, le temps de recherche est log (n) [base k]. Par conséquent, si k = 10, pour 1 milliard d'entrées, seulement 9 itérations seront nécessaires.

Toutes les bases de données enregistrent les index des clés primaires dans les arbres B. Par conséquent, la tâche indiquée ne serait pas coûteuse, et vous devriez aller de l'avant et concevoir la base de données comme il semblait évident. PS: Vous pouvez créer un index sur n'importe quelle colonne de la table. Par défaut, les index de clé primaire sont déjà stockés. Mais attention, ne faites pas d'index inutiles car ils prennent de l'espace disque.