Хранение текста отдельно или вместе с остальными данными

Есть таблица сообщений форума POSTS: id_post, id_topic, id_poster, name_poster, date_time_post, post_text.
Вопрос на счет хранения текста поста в таблице POSTS.

Конкретно: не лучше ли будет хранить текст постов в отдельной таблице, где будет id_post и post_text?

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

Теперь вот что нашел на эту тему:

А: У меня таблица на 5Гбайт, скорость извлечения по целочисленному ключу зависит только от числа строк (коих около 2 млн). От наличия текста - не зависит. Б: Вы имели ввиду, что скорость зависит лишь от числа строк, но не от количества гигов таблицы? А: Именно так. А так - да, когда-то и сам разносил тексты в отдельную таблицу... Но это только лишняя нагрузка в виде лишнего JOIN при выборке. А пользы никакой. По крайней мере в моём случае (БД сообщений форума).

Так где же истина??

Буду благодарен любым ответам.

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

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

Хмм...

Читал, что MySQL хранит поля text и blob отдельно от остальных данных... Хотя так же встречал противоречивые мнения по этому поводу.
10.5. Data Type Storage Requirements: […] For BLOB and TEXT data, the information is stored internally in a different area of memory than the row buffer. […]

Основной запрос к таблице постов будет на формирование определённой страницы при просмотре топика.
Например хочу просмотреть 3-ю страницу (на страице выводится по 20 постов) топика с ID = 21:

SELECT * FROM posts WHERE id_topic = 21 ORDER BY id_post LIMIT 40, 20

Как будет вести себя MySQL в данном случаес полем post_text и вообще с запросом?
Или можно как-то подругому более оптимально представить данный запрос...

MySQL хранит таблицу в трёх файлах (структура, данные и индексы)
А вот Paradox (расширение .db) действительно для МЕМО полей использовал отдельный файл.

Что касается личного опыта - у меня самая большая таблица около 15Гб (более 40 миллионов записей), и у меня никогда небыло мысли разносить данные и МЕМО по разным таблицам. Это же потом чёрт голову сломит склеивать их JOIN'ом. А так за тысячные доли секунды зарос выполняется.

А в вашем примере MySQL по индексному файлу отберёт 20 первых сообщений с топика №21 и потом по индексам выберет данные из основного файла. Думаю даже на миллионную долю секунды вы не ускорите этот запрос разнеся данные по двум таблицам (а вот на склеивании будете терять время!)

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