Наиболее эффективный дизайн базы данных для блога (посты и комментарии)

Question

Каков наилучший способ создания базы данных для хранения постов и комментариев в блоге?В настоящее время я думаю, что одна таблица для сообщений, а другая для комментариев, каждая с идентификатором сообщения.

Однако мне кажется, что просмотр большой таблицы комментариев, чтобы найти их для соответствующего сообщения, будет дорогими будет выполняться каждый раз при загрузке сообщения в блоге (возможно, с некоторым объемом кэширования).

Есть ли лучший способ?

Answer 1

Мне, однако, кажется, что мы просматриваем большую таблицу комментариев

Все поставщики баз данных согласны с вами.

Они предлагают "индексы" для ограниченияэтот.

Answer 2

Каждая система баз данных, которую вы будете использовать для реализации своего блога, будет использовать индексирование .Это означает, что вместо того, чтобы «перелистывать большие таблицы», ваша система баз данных поддерживает отдельный список комментариев и сообщений, с которыми они связаны, очень похоже на индекс в конце книги.Это позволяет системе базы данных загружать комментарии, связанные с постом, очень быстро, и я не вижу проблем с вашим предложенным дизайном для блога любого размера.

Индексы обычно используются для связи таблиц с миллионами строк с другими таблицами с миллионами строк - вам понадобится исключительно большой блог, чтобы потребовать денормализации комментариев, и даже тем не менее кэширование, вероятно, послужит вам далеколучше, чем денормализация базы данных.

Вам необходимо определить индекс в таблице комментариев и связать его с любым столбцом, в котором содержится идентификатор сообщения.Как это сделать, зависит от того, какую систему баз данных вы используете.

Answer 3

попробуйте что-то вроде этого:

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 4

Хорошо, посмотрим.

просмотр большой таблицы комментариев, чтобы найти комментарии к соответствующей записи, будет дорогим

Почему вы думаете, что это будет дорого? Потому что вы, возможно, полагаете, что линейный поиск будет выполняться каждый раз за O (n) времени. Для миллиарда комментариев будет сделано миллиард итераций.

Теперь предположим, что двоичное дерево поиска построено для comment_ID. Чтобы посмотреть любой комментарий, вам нужен log (n) time [base 2]. Так что даже для 1 миллиарда комментариев потребуется всего около 32 итераций.

Теперь рассмотрим слегка модифицированный BST, где каждый узел содержит k элементов вместо 1 (в списке) и имеет k + 1 дочерних узлов. Те же самые свойства BST соблюдаются и в этой структуре данных. То, что у нас здесь, называется B-деревом. More reading: GeeksForGeeks - B Tree Введение

Для B-дерева время поиска составляет log (n) [base k]. Следовательно, если k = 10, для 1 миллиарда записей потребуется только 9 итераций.

Все базы данных сохраняют индексы для первичных ключей в B-Trees. Следовательно, заявленная задача не будет дорогой, и вам следует разработать базу данных так, как это казалось очевидным.

PS: Вы можете построить индекс для любого столбца таблицы. По умолчанию индексы первичного ключа уже сохранены. Но будьте осторожны, не создавайте ненужных индексов, так как они занимают место на диске.

Answer 5

трал через большой стол комментарии, чтобы найти те для соответствующий пост будет дорогим,

Индекс всегда рядом, чтобы спасти вас! Первый индекс на postId и другой на commentdate (desc)