Стоит ли разделять таблицу на две (поля для выборки и содержимое)?
Господа, имеет ли смысл выделить содержимое в отдельную таблицу и цеплять её поля через join? Таблица состоит из полей, участвующих в выборке (индексированы) и содержимого (varchar, текстовые поля, а также дополнительные поля, не участвующие в выборке).
Без конкретики (структура таблицы, индексов, объем данных, запрос) любой ответ это "пальцем в небо". Но в большинстве случаев разбивать таблицу не стоит.
Нет, зачем? Нет никакой проблемы в том, что таблица будет широкой. Разбиение на несколько таблиц имеет смысл, если оно приведет к нормализации данных и уменьшению объема хранимой информации. Кроме того, нет никакой необходимости индексировать поля, которые участвуют в выборке, но не используются для фильтрации данных. Если очень хочется смотреть на узкую таблицу с только необходимыми полями - сделайте view без разбиения исходной таблицы.
Кроме того, нет никакой необходимости индексировать поля, которые участвуют в выборке, но не используются для фильтрации данных.
Без этого действительно можно обойтись, но вообще, есть такая вещь, как покрывающие индексы, которые позволяют к таблице для определённых запросов вообще не обращаться.
Под индексированием я всё же имел в виду поля, участвующие в фильтрации (where).
Я предположил, что выборка будет быстрее, если таблица будет содержать только поля, по которым будет производиться фильтрация where, а затем уже добавляться через left join нужные поля с текстовым содержимым.
К примеру, двухуровневые (с возможностью отвечать) комментарии я сделал так:
1) Запрашиваются все комментарии с ключом post_id
2) Они сортируются так, что на выходе остаются 15 комментариев верхнего уровня (последние добавленные, либо с наибольшим рейтингом), а также до 5 комментариев-ответов на каждый из них.
3) Отдельным запросом из второй таблицы загружается остальное содержимое отобранных ранее комментариев.
Повода для дробления таблицы с комментариями здесь не вижу, только дополнительный индекс по второй таблице появляется, который будет идентичен первому (в двух таблицах мы имеем id поста + id комментария)
Оффтоп - на досуге можете почитать use-the-index-luke.com
Помогает структурировать то, что Вы уже знали и уверен, почерпнете нового для себя.
Третья нормальная форма
Пока таблица соответствует данным требованиям, разбивать ее смысла не имеет. Скорость работы индекса не зависит от наличия других полей в таблице.
Разве что будет возникать необходимость архивации данных. Но и тогда бы я думал в сторону партиционирования таблицы, а не выделения комментариев в отдельную.
Павел: то есть, если таблицу не разбивать, но при первом запросе брать лишь мета-данные всех комментариев к статье для сортировки, исключив из выборки text-содержимое, скорость выборки и затраты ресурсов будут такие же, как если бы в этой таблице были лишь мета-данные без содержимого? В принципе, суть моего вопроса именно вокруг этого момента.
Anubis: Понял Вашу проблему. Тогда главное, чтобы поле сортировки было индексировано, а еще лучше - входило в составной индекс, используемый при фильтрации (запросы не пользовательские, а зафиксированы в движке сайта, поэтому может иметь смысл). Подробнее механика работы описана тут. В этом случае обращение к данным самой таблицы буде только в самом конце, при отображении результата.
