Есть проверенная структура, для хранения типа: Мультиблогинга?
Есть 500 000 названий тем (это основа блога)
По каждой теме, пользователь может создавать свой пост.
Под каждым постом можно оставлять комментарии.
-------------------
Открывая страницу с названием темы, например id 1234567
Мне нужно получить все посты для нее + количество комментариев для каждого поста и пользователя поста.
Открывая пост, нужно получить все комментарии + пользователя.
-------------------
У поста обязательные поля - название, текст, тип поста.
Вроде бы ничего сложного нет и можно сделать разными способами. Но вот как потом?
Ведь 500 000 тем, допустим за год под каждой 1000 постов, а под каждым постом 100 комментов.
-------------------
Поэтому вопрос:
Может кто работал с большими данными, как лучше в такой ситуации сделать связи таблиц?
Нужно ни таблицу пост разделить на две? В одной хранить названия и все связи, а в другой текста, так как они могут быть большими. Какая логическая схема будет правильной?
Как пример, это группы в VK, группы это темы, у тем есть посты, а у постов комментарии.
Мне кто то советовал, но в данном случае документо-важным тут только текст постов. Я если правильно понимаю, документные бд для хранения текста больших объемов. Где нет такой логики связей и условий при чтении как в MySQL-подобных.
Для правильного вопроса надо знать половину ответа
Ничего особо сложного в этой схеме нет, обычная связь один-ко-многим. В посте указывается id темы, в комментарии - id поста. Если комментарии древовидные, то ещё добавляются поля для nested set, тогда удобно выбирать целиком ветки комментариев.
Для того, чтобы не считать каждый раз количество комментариев создаётся поле, увеличивающееся триггером при добавлении комментария.
Ну и, естественно, нужны правильно составленные индексы.
Что значит правильно составленные индексы? На сколько я читал документацию, они или просто создаются на поле или не создаются. Получается создать индексы на связующие поля? И я с вами согласен на счет промежуточных таблиц, много думал и не нашел причину, по которой бы они давали плюс в данной схеме... А поле count comment часто может меняться, поэтому думаю без тригера, а просто получать число пересчетом при добавлении или удалении.
Вы предлагаете, я смотрю в документацию, сравниваю примеры, логически делаю вывод, и ставлю Вам плюс. Я рассматривал около 3-х схем хранения данных в данном случае. Проведя тесты с 1 500 000 темами, я "выдирал" связями комменты, например через "тему", как в примере за 0.9s что очень много для продакшн, но составные индексы сделали свое дело. Но я сделаю все таки через двойной POST таблицу, и вот по чему... Дело в том, что при выборе темы именно в данном проекте, нужны только заголовки постов. Поэтому учитываю их количество, а так же обязательное состояние иметь текст до огромных размеров, я вынесу текст в отдельную таблицу. Так как текст поста нужен именно при обращении к нему. В итоге все один ко многим, единственное еще я сделаю комментарии "Через полиморфные" то есть - Through Polymorphic как то так, потому что планирую ту же структуру комментов в других разделах.
Средний
