Что касается производительности, целостности и дискового хранилища на уровне базы данных, я бы не беспокоился об этом.
- Данные переменной длины, такие как varchar, text и blob, хранятся безpadding.
- Я не знаю проблем с целостностью.Все типы данных обрабатываются ядром базы данных атомарно.
- Конечно, если у вас действительно длинные текстовые данные, потребуется больше памяти и больше времени для дискового ввода-вывода и пропускной способности сети при извлечении этих данных.Но если это те данные, которые вам нужно поместить в базу данных, то это то, что вам нужно сделать.
Я могу подумать об одном из возможных последствий:
Некоторые библиотеки клиентских интерфейсов предварительновыделить буфер для хранения результатов, и они выделяют достаточно памяти для максимально возможного значения.Клиент не знает длину данных, прежде чем он извлекает данные, поэтому он должен выделить достаточно места, если предположить, что данные могут быть такими, как поддерживает тип данных.
Поэтому библиотека будет выделять 16 МБ на mediumtext, в то время как он выделит 64 КБ для text.Это то, на что нужно обратить внимание, если у вас низкий предел памяти на уровне клиента.Например, PHP имеет параметр конфигурации memory_limit для сценариев, и буфер, выделенный для наборов результатов данных, будет учитываться при этом.