Стоит ли разделять таблицу на две (поля для выборки и содержимое)?

Question

[Anubis]

Господа, имеет ли смысл выделить содержимое в отдельную таблицу и цеплять её поля через join? Таблица состоит из полей, участвующих в выборке (индексированы) и содержимого (varchar, текстовые поля, а также дополнительные поля, не участвующие в выборке).

Comments

[ComodoHacker]

Без конкретики (структура таблицы, индексов, объем данных, запрос) любой ответ это "пальцем в небо". Но в большинстве случаев разбивать таблицу не стоит.

Answer 1

[Павел]

Нет, зачем? Нет никакой проблемы в том, что таблица будет широкой. Разбиение на несколько таблиц имеет смысл, если оно приведет к нормализации данных и уменьшению объема хранимой информации. Кроме того, нет никакой необходимости индексировать поля, которые участвуют в выборке, но не используются для фильтрации данных. Если очень хочется смотреть на узкую таблицу с только необходимыми полями - сделайте view без разбиения исходной таблицы.

Comments

[Алексей Уколов]

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

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

[Anubis]

Под индексированием я всё же имел в виду поля, участвующие в фильтрации (where).

Я предположил, что выборка будет быстрее, если таблица будет содержать только поля, по которым будет производиться фильтрация where, а затем уже добавляться через left join нужные поля с текстовым содержимым.

К примеру, двухуровневые (с возможностью отвечать) комментарии я сделал так:
1) Запрашиваются все комментарии с ключом post_id
2) Они сортируются так, что на выходе остаются 15 комментариев верхнего уровня (последние добавленные, либо с наибольшим рейтингом), а также до 5 комментариев-ответов на каждый из них.
3) Отдельным запросом из второй таблицы загружается остальное содержимое отобранных ранее комментариев.

Если можно поступить оптимальней, поправьте меня.

[Павел]

Повода для дробления таблицы с комментариями здесь не вижу, только дополнительный индекс по второй таблице появляется, который будет идентичен первому (в двух таблицах мы имеем id поста + id комментария)

Оффтоп - на досуге можете почитать use-the-index-luke.com
Помогает структурировать то, что Вы уже знали и уверен, почерпнете нового для себя.

[Anubis]

Павел: во второй таблице только primary по id комментария.

select ... from comments where post_id = ...
...
select ... from comments c left join comments_content cc on cc.id = c.id where c.id in (...)

[Anubis]

Вру, во втором запросе получаю данные только из comments_content, т.к. данные из comments уже получены ранее

[Павел]

Третья нормальная форма
Пока таблица соответствует данным требованиям, разбивать ее смысла не имеет. Скорость работы индекса не зависит от наличия других полей в таблице.

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

[Anubis]

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

[Павел]

Anubis: Понял Вашу проблему. Тогда главное, чтобы поле сортировки было индексировано, а еще лучше - входило в составной индекс, используемый при фильтрации (запросы не пользовательские, а зафиксированы в движке сайта, поэтому может иметь смысл). Подробнее механика работы описана тут. В этом случае обращение к данным самой таблицы буде только в самом конце, при отображении результата.