организация таблиц для хранения текстов

Всем привет. Всех с наступившим.
Вопрос. Существует система на php+mysql ,в ней могут регистрироваться множество пользователей. Эти пользователи могут добавлять в систему свои записи. От пары символов до текстов по объему равных Войне и миру.
Функционал системы -добавление записей, вывод записей конкретного пользователя, поиск по записям конкретного пользователя. Вывод всех пользователей, поиск по записям всех пользователей. Ориентировочно 1 пользователь будет добавлять в год от 500 текстов +-.

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

id | name | text | user_id

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

ну для огромных текстов есть тип TEXT и связанные с ним в бд, не говоря уже про просто BLOB.
И, кстати, что такое огромные текст?
Так-то война и мир в чистом виде занимает ~3мб(первая что нагуглил). Это совсем не много и легко вместится в стандартный LONGTEXT.

Ну а для текстов, которые больше LONGTEXT-а можно проверять размер и бить на части, и писать в соотв-ю табличку частями.

vital
т.е. фактически для больших текстов должна быть доп таблица?

Если вдруг у вас будет текст, который больше чем тип LONGTEXT (что вряд ли, война и мир короче в полтора-два раза), то да, стоит вынести текст - как отдельную сущность, соотв-но дробить тексты на части, и писать в эту таблицу храня соотв-е каждой части к какой сущности эта часть относится и какая она по порядку.

НО.
Если не критично время ответа страницы (если 10-20-30ms не критичны для вас, а я думаю не критичны), как вариант попробуйте ваши тексты просто жать каким-нить зипом при записи, и при выводе распаковывать, а писать соотв-но просто в BLOB. Тексты очень хорошо и, я думаю, быстро жмутся. Вряд ли вы встретите текст, который сжатый в зип выйдет из размеров LONGBLOB. Но да, с точки зрения универсальности и надежности первый вариант правильнее.

А еще.
А вы уверены что вам надо mysql ?
Возьмите какой-нить Redis, у него максимальный размер строки вообще 512мб. Это пол-интернета в тексте. Да и удобнее работать вам будет, чем с SQL в данном случае, имхо.

vital
благодарю

В несжатом виде база сообщений нашего форума больше гигабайта.

А если почитать доку?

можно id объединить с user_id сделав ключ составным по id и name. Вопрос

упирается в вопрос: каков бюджет мероприятия?

В несжатом виде база сообщений нашего форума больше гигабайта.

Я люблю утрировать, да. Ну так-то база форума не связанный текст, и собрана годами, и блаблабла. Короче давайте лучше занудамоде=офф

А если почитать доку?

Для однобайтной кодировки 1 символ = 1 байт(можете проверить с помощью блокнота), для боговерного двухбайтового юникода 2 соответственно.

Ну разделите на 1024 несколько раз, приняв что размер войны и мир меньше 3х мб.
Где я не прав? Что не соотв-т доке?

я бы этого не делал, и другим бы не советовал
id с user_id составной уникальный можно сделать

Быть Вам финансистом Партии и Правительства! ... во веселуха будет

Не получится. Потому как топикстартер некорректно поставил вопрос. Ничего не сказано о целях хранения информации.
На примере движка этого форума, у нас существуют 3 параллельных способа хранения информации:
1. В БД текстовые поля - доступные поиску.
2. В gz-файлах. Для экономии дискового пространства. Для больших текстов. Есть возможность поиска средствами пхп.
3. Зазипованные в БД в поле blob. Для маленьких текстов. Потому что если их хранить в файлах, будут большие потери на кластеризации.

я бы этого не делал, и другим бы не советовал
id с user_id составной уникальный можно сделать

id === user_id и тогда id | name | content, private key (id, name) будет состоять во 2 н.ф. что не так плохо. Если конечно это высоко нагруженный проект тогда надо по другому, но так как человек хочет что-то простое, для душу смастерить то в самый раз.

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