Когда имеет смысл делать несколько таблиц с комментариями?
1) Если речь идет о форуме, то есть ли смысл автоматически создавать новую таблицу комментариев для каждой новой темы?
2) Тот же вопрос о статейном сайте, где под каждой статьей будет до 50 комментариев в среднем.
3) Наличие отдельных таблиц ускорит загрузку? Ведь если имеется 100 тем и к каждой оставляется примерно 100 комментариев, то в случае с объединенной таблицей система пробегает 10 000 комментариев, но если отдельные таблицы, то система ищет между 100 таблицами, и получается в 100 раз быстрее?
4) Есть ли разница в скорости пробега по одной таблице или списке таблиц такой же длины?
О, набежали подписанты )
Идея дурацкая и вредная, всем коментам место в одной таблице, и быстрее будет, и сохраннее.
Почитать про индексы даже не советую - бесполезно.
И получается дико неудобно и значительно медленнее в итоге.
Не касаясь лимита на число открытых файловых дескрипторов, кучу internal статистики планировщика и прочих деталей реализации.
Форум. Банальная страница профиля пользователя, достать последние 10 сообщений этого пользователя - как? union all по всем темам с filesort последующим вместо простого index scan по составному ключу даже без необходимости в сортировке?
Статьи. Показать для модерации последние комментарии
А распилить большую таблицу (только на самом деле большую, а не в смешные лям строк) на части - вещь неплохая. Только не так надо пилить. Есть у mysql штатное партицирование.
1. У вас на форуме 1000 тем, у вас будет 1000 таблиц для каждой темы?
В чем проблема создать просто таблицу комментариев где будут храниться поля
id
user_id
post_id
text
2. Таже самая схема что и в 1 случае выше
3. Как вы хотите потом запросы писать то? У вас проект умрет на поддержке. Если построить продуманный запрос, то со скоростью все будет нормально.
4. На это вопрос не могу дать ответа. Попробуйте создать бд и протестировать. Конечно таблица в 100 000 строк будет обрабатываться медленнее чем 10 000 таблиц в которых 10 записей
Я предполагаю что да. Как потом запросы писать? Вы если проектируете базу, вы должны думать о бекенде, как потом это будет автоматизироваться?
Так же как дизайнер должен думать о верстальщике.
Это вариант шардирования по таблицам.
На ваших числах смысла не имеет. Да, будет быстрее выборка комментариев к одному посту, но едва ли покроет накладные расходы на чтение из разных таблиц, т.к. скорее всего будут запросы не просто "дай комментарии к этому посту", а например "посчитай комментарии к постам на первой странице с группировкой по посту".
Имеет смысл, если у вас очень немного постов, в пределах пары сотен и в них очень много комментариев - миллионы или даже десятки миллионов. Но это не подходит не под один из описанных случаев.
Да вот думаю, такие форумы, как ЯплакалЬ или тот же хабр-хабр ведь когда-то начинали с малого, на ЯплакалЬ некоторые темы обсуждаются годами, видела одну с возрастом 4 года. Реально ли с такой нагрузкой работать на одной таблице?
kally, Возможно реально. Но тут уже зависит не столько от количества комментариев, сколько от количества запросов в секунду. При их масштабах там скорее всего есть шардирование, но на другом уровне. Например, посты раскладываются по таблицам на нескольких шардах и комментарии к этим постам хранятся на этих же шардах по одной таблице на каждый шард.
Простой
