Предположительно, вы исключили альтернативу хранения этих элементов текста в файлах и сохранения их путей в вашей таблице. Если вы не рассматривали этот выбор, сделайте это. Зачастую это самый практичный способ работы с такого рода приложениями. Это особенно верно, если вы используете веб-сервер для доставки информации своим пользователям: помещая эти объекты в свою файловую систему, вы избегаете очень серьезного производственного узкого места (извлечение объектов из СУБД и их последующая отправка пользователю).
Большие объекты MySQL (большие объекты) без проблем будут принимать 300 тыс. символов. MEDIUMTEXT обрабатывает 16 мегабайт. Но работа по программированию, необходимая для загрузки этих объектов в СУБД и их повторного извлечения, может быть немного сложной. Вы не упомянули свой стек приложений, поэтому трудно дать вам конкретный совет по этому поводу. Когда начать? читайте о параметре сервера MySQL max_allowed_packet
.
Если бы это был мой проект, и по какой-то причине использование файловой системы не могло быть и речи, я бы хранил большие текстовые статьи в виде сегментов в более коротких строках. Например, вместо
textid textval
(int) (MEDIUMTEXT)
number lots and lots and lots of text.
Я бы сделал такую таблицу:
textid segmentid textval
(int) (int) (VARCHAR(250))
number 1 Lots and
number 2 lots and
number 3 lots of
number 4 text.
Длина сегмента, вероятно, должна составлять около 250 символов каждый. Я думаю, вы были бы умны, если бы могли разбить сегменты на границах слов; это упростит такие вещи, как полнотекстовый поиск. Это приведет к появлению множества более коротких строк для ваших больших текстовых элементов, но это сделает ваше программирование, ваши резервные копии и все остальное в вашей системе. легче обрабатывать все вокруг.
Предоплата есть, но, наверное, она того стоит.
person
O. Jones
schedule
29.11.2014
MEDUMTEXT
позволяет использовать до 2^24 байт, что составляет около 16 МБ.LONGTEXT
позволяет 2 ^ 32, около 4 ГБ. - person Barmar   schedule 29.11.2014