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