Есть ли недостатки использования типа данных "текст" для хранения строк?

Question

Согласно документации Postgres, они поддерживают 3 типа данных для символьных данных:

character varying(n), varchar(n)  variable-length with limit
character(n), char(n)             fixed-length, blank padded
text                              variable unlimited length

В моем приложении я столкнулся с несколькими неприятными сценариями, в которых запросы вставки / обновления не выполнялись, так как требуемый текст для вставки превышал varchar(n) или же char(n) предел.

Для таких случаев изменение типа данных таких столбцов на text хватило.

Мои вопросы:
Если мы обобщим и изменим тип данных каждого столбца хранения символов на textЕсть ли какие-либо недостатки с точки зрения производительности / памяти?
Если столбец с типом данных text хранит 10 или менее символов каждый раз, я должен пойти на text или же varchar(10)?
Если я пойду на text в чем минус?

Answer 1

Как правило, нет недостатка в использовании text с точки зрения производительности / памяти. Напротив: text является оптимальным. Другие типы имеют более или менее соответствующие недостатки. @Quassnoi и @Guffa уже пролили свет на это.

В частности, никогда не используйте char или же char(n) (псевдоним для character / character(n)), если вы не знаете, что делаете. Этот тип с пробелами только для совместимости со старым кодом и стандартами. В настоящее время это имеет мало смысла, тратит память и может вызвать проблемы:

• Сравните varchar с символом
• Длина строкового поля в Postgres SQL

Чтобы обеспечить максимальную длину столбца, по-прежнему используйте text (или же varchar без спецификатора длины, что в принципе то же самое), а не varchar(n) (псевдоним для character varying / character varying(n)). CHECK ограничение гораздо удобнее менять позже (без перезаписи таблицы), тем более, когда представления, функции, ограничения FK и т. д. зависят от типа столбца.

ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 100);

CHECK Ограничение также может сделать больше, чем просто принудительно установить максимальную длину символа - все, что вы можете поместить в логическое выражение. Прочитайте больше:

• Изменить столбцы PostgreSQL, используемые в представлениях

Наконец, есть также "char" (с двойными кавычками): 1-байтовый тип данных для одной буквы ASCII, используемый в качестве дешевого типа внутреннего перечисления.

Я редко использую что-либо, кроме text для символьных данных в Postgres.

Answer 2

Со страницы, на которую вы ссылались:

"Между этими тремя типами нет никакой разницы в производительности, за исключением увеличения места для хранения при использовании типа с пробелом и нескольких дополнительных циклов ЦП для проверки длины при сохранении в столбце с ограниченной длиной. Хотя символ (n) имеет производительность преимущества в некоторых других системах баз данных, в PostgreSQL такого преимущества нет; на самом деле символ (n) обычно самый медленный из трех из-за дополнительных затрат на хранение. В большинстве случаев вместо текста следует использовать изменение текста или символа."

Кажется, нет никаких недостатков использования text Тип данных в Postgres.

Однако вам следует подумать, действительно ли вы хотите разрешить хранить огромные тексты в базе данных. Держать это как varchar но с более высоким пределом защитит вас от непреднамеренного хранения огромных объемов данных в базе данных.

Answer 3

Все типы данных, которые вы упоминаете, используют одно и то же внутреннее представление (умеренно известный struct varlena)

CHAR а также VARCHAR типы данных просто добавляют проверки длины к этому, и (в случае CHAR), имеют разную семантику отступов.

Ты можешь использовать TEXT безопасно везде, где ничего из вышеперечисленного не важно для вашей логики.