Design di database più efficiente per un blog (post e commenti)

Question

Quale sarebbe il modo migliore di progettare un database per archiviare post e commenti di blog? Attualmente sto pensando a una tabella per i post e un'altra a commenti, ognuno con un ID post.

Mi sembra, tuttavia, di sciare attraverso una grande tabella di commenti per trovare quelli per il post in questione sarebbe costoso, e sarebbe fatto ogni volta che un post del blog viene caricato (forse con una certa quantità di memorizzazione nella cache).

C'è un modo migliore?

Answer 1

Mi sembra, però, pesca a strascico attraverso un grande tavolo di commenti

Tutti i fornitori di database sono d'accordo con te.

Offrono "indici" per limitare questo.

Answer 2

Ogni sistema di database che utilizzeresti per implementare il tuo blog utilizzerà l'indicizzazione . Ciò significa che, anziché "navigare su una grande tabella", il tuo sistema di database mantiene un elenco separato di commenti e quali post sono associati, proprio come l'indice nella parte posteriore di un libro. Ciò consente al sistema di database di caricare i commenti associati a un post estremamente rapidamente, e non vedo alcun problema con il progetto proposto per un blog di qualsiasi dimensione.

indici sono abitualmente utilizzati per associare le tabelle con milioni di righe con le altre tabelle con milioni di righe - che avrebbe dovuto avere un eccezionalmente grande blog per richiedere denormalizzazione di commenti, e persino ancora, la cache probabilmente vi servirà molto meglio di denormalizzare il database.

È necessario definire un indice nella tabella dei commenti e associarlo a qualsiasi colonna che contiene l'ID postale. Il modo in cui ciò avviene dipende dal sistema di database che si sta utilizzando.

Answer 3

pesca a strascico attraverso un grande tavolo di commenti per trovare quelli per la messaggio in questione sarebbe costoso,

Un indice è sempre lì a salvarti! In primo indice su postId e un altro di commentdate (decrescente)

Answer 4

provare qualcosa di simile:

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

Va bene, vediamo.

pesca a strascico attraverso un grande tavolo di commenti per trovare quelli nel messaggio in questione sarebbe costoso

Perché pensi che sarebbe costoso? Perché probabilmente credi che una ricerca lineare verrà eseguita ogni volta che impieghi O (n) tempo. Per un miliardo di commenti, verrà effettuato un miliardo di iterazioni.

Supponiamo ora di costruire un albero di ricerca binario per comment_ID. Per cercare qualsiasi commento, è necessario log (n) time [base 2]. Quindi, anche per 1 miliardo di commenti, saranno necessarie solo circa 32 iterazioni.

Considerare ora un BST leggermente modificato, in cui ogni nodo contiene k elementi anziché 1 (in un elenco) e ha nodi k + 1 figli. Le stesse proprietà di BST sono seguite anche in questa struttura dati. Quello che abbiamo qui è chiamato B-tree. Ulteriori letture: GeeksForGeeks - B Tree Introduction

Per un B-Tree, il tempo di ricerca è log (n) [base k]. Quindi, se k = 10, per 1 miliardo di voci, saranno necessarie solo 9 iterazioni.

Tutti i database salvano gli indici per le chiavi primarie in B-Trees. Quindi, il compito dichiarato non sarebbe costoso, e dovresti procedere e progettare il database nel modo in cui sembrava ovvio.

PS: è possibile creare un indice su qualsiasi colonna della tabella. Per impostazione predefinita, gli indici delle chiavi primarie sono già memorizzati. Ma attenzione, non creare indici inutili quando occupano spazio su disco.