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

Quelle serait la meilleure manière de la conception d'une base de données pour stocker les messages blog et les commentaires? Je suis actuellement en train de penser à une table pour les poteaux, et un autre pour les commentaires, chacun avec un post ID.

Il me semble, cependant, le chalutage par le biais d'un grand tableau d'observations pour trouver ceux pour le message serait coûteux et pourrait être fait à chaque fois qu'un blog est chargé (peut-être avec une certaine quantité de cache).

Est-il un meilleur moyen?

source d'informationauteur tsvallender

  1. 17

    Il me semble, cependant, le chalutage par le biais d'un grand tableau d'observations

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

    Ils offrent des "indices" pour limiter cet effet.

  2. 13

    Chaque système de base de données que vous utiliserez pour mettre en œuvre votre blog, vous utilisez indexation. Ce que cela signifie, c'est que, plutôt que "le chalutage par le biais d'un tableau de grande taille", votre système de base de données maintient une autre liste de commentaires et de messages qui ils sont associés, à l'instar de l'index à la fin d'un livre. Cela permet au système de base de données pour charger les commentaires associés à un poste très rapidement, et je ne vois pas de problèmes avec votre proposition de design pour un blog de toute taille.

    Indices sont couramment utilisés pour associer les tables avec des millions de lignes avec d'autres tables avec des millions de lignes - vous devez disposer d'un vaste blog pour exiger la dénormalisation de commentaires, et de même encore, la mise en cache serait probablement vous servir beaucoup mieux que la dénormalisation de la base de données.

    Vous aurez besoin de définir un index sur vos commentaires de la table, et l'associer avec ce que l'colonne contient l'ID de la Poste. Comment c'est fait dépend de ce système de base de données que vous utilisez.

  3. 7

    essayer quelque chose comme cela:

    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
...
  4. 1

    le chalutage par le biais d'une grande table de
    commentaires pour trouver ceux pour la
    message serait coûteux,

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

  5. 1

    Bon, voyons voir.

    le chalutage par le biais d'un grand tableau d'observations pour trouver ceux pour le message serait coûteux

    Pourquoi pensez-vous qu'il serait coûteux? Parce que vous croyez qu'un linéaire de recherche sera fait à chaque fois de prendre O(n) fois. 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 devez log(n) temps [base 2]. Donc, même pour 1 milliards de commentaires, seulement 32 itérations seront nécessaires.

    Considérons maintenant un peu modifié la STB, où chaque nœud contient les éléments k au lieu de 1 (dans une liste) et a k+1 nœuds enfants. Les mêmes propriétés que le BST sont suivis dans cette structure de données. Ce que nous avons ici est appelé un B-arbre. En savoir plus : GeeksForGeeks - B Arbre Introduction

    Pour un B-Arbre, la recherche du temps est log(n) [base k]. Donc, si k=10, pour 1 milliard d'entrées, seulement 9 itérations seront nécessaires.

    Toutes les bases de données enregistrer les indices pour les clés primaires dans les B-Arbres. Par conséquent, la tâche ne serait pas à être coûteux, et vous devriez aller de l'avant et de la conception de la base de données de la façon dont il semblait évident.

    PS: Vous pouvez créer un index sur une colonne de la table. Par défaut, la clé primaire, les indices sont déjà stockées. Mais attention, ne faites pas inutiles les indices qu'ils prennent de l'espace disque.