MySQL лучший способ хранения длинных строк

Я ищу несколько советов о том, как наилучшим образом хранить длинные строки данных от экспертов mySQL.

У меня есть таблица общего назначения, которая используется для хранения любых данных, и я имею в виду, что она должна содержать буквенно-цифровые и числовые данные. В настоящее время структура таблицы проста с идентификатором и фактическими данными, хранящимися в одном столбце, следующим образом:

id INT(11)
data VARCHAR(128)

Теперь у меня есть требование хранить больший объем данных (до 500 символов), и мне интересно, будет ли лучший способ просто увеличить размер столбца varchar или добавить новый столбец (тип TEXT столбец?) для времени, в котором мне нужно хранить более длинные строки.

Если у любого эксперта есть какие-то советы, я все уши! Мой предпочтительный метод состоял бы в том, чтобы просто увеличить столбцы varchar, но это потому, что я ленив. Версия mySQL, на которой я запущена, составляет 5.0.77.

Я должен упомянуть, что новое требование для 500 символов будет только для нечетной записи; большинство записей в таблице не должно превышать 50 символов. Я думал, что буду проверять будущее, сделав столбец 128. Показывает, насколько я знал!

Ответ 1

Вообще говоря, это не вопрос, который имеет "правильный" ответ. В MySQL нет типа хранения "бесконечной длины". Вы можете использовать LONGTEXT, но у него все еще есть (абсурдно высокий) верхний предел. Но если вы это сделаете, вы пинаете свои СУБД в зубах за то, что имеете дело с этим абсурдным блобом столбца для вашего 50-символьного текста. Не говоря уже о том, что вы с ней ничего не делаете.

Таким образом, наибольшая будущая устойчивость (TM), вероятно, предлагается LONGTEXT. Но это также очень плохой метод решения проблемы. Честно говоря, я бы пересмотрел требования к приложениям. Хранение строк, которые не имеют "домена" (как, будучи четко определены в их приложении) и произвольной длины, не является одной из сильных сторон РСУБД.

Если бы я решил решить эту проблему на уровне "дизайн приложения", я бы использовал для этого хранилище ключей для NoSQL (и я как шутер от NoSQL по мере их получения, так что вы знаете это серьезно), хотя я признаю это довольно дорогостоящим изменением для таких незначительных изменений. Но если это указывает на то, что ваша СУБД в конечном итоге будет удерживать, может быть более разумным перейти сейчас, чтобы избежать этой же проблемы сто раз в будущем. Домен данных очень важен в СУБД, тогда как он явно ограничен в нереляционных решениях, которые, как представляется, вы пытаетесь решить здесь.

Застрял с MySQL? Просто увеличьте его до VARCHAR(1000). Если у вас нет требований к вашим данным, это не имеет значения, что вы делаете в любом случае.

Ответ 2

Осторожнее при использовании текста. Данные TEXT не хранятся в памяти серверов базы данных, поэтому всякий раз, когда вы запрашиваете данные TEXT, MySQL должен считывать их с диска, что намного медленнее по сравнению с CHAR и VARCHAR, поскольку он не может использовать индексы. Лучший способ хранить длинные строки будут базы данных nosql