@Ispanec1998

Есть ли разница для скорости работы БД при установке типа text, а не varchar 128?

Есть ли разница для скорости работы БД при установке типа text, а не varchar 128?
Столкнулся с ситуацией, что 128 символов для одной колонки стало недостаточно
Есть ли смысл так разграничивать типы колонок по типу varchar, а не text?
Или можно везде ставить text и не париться?
  • Вопрос задан
  • 354 просмотра
Решения вопроса 4
iMedved2009
@iMedved2009
Не люблю людей
Don't use varchar(n) by default

З.Ы. Однако наверное стоит не забывать про Toast
Ответ написан
@rPman
varchar/text/bytea в postgres используют одну и ту же технологию хранения и производительность будет напрямую зависеть от реального размера строк и от оптимизаций
https://habr.com/ru/company/tensor/blog/498292/
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Лимиты на текстовые поля - это архаизм и пережитки старины далёкой. Они имели большой смысл для DBase, Clipper, FoxPro но для современных БД практически уже неактуальны. Можно брать text.
Даже Oracle вобщем-то снял лимит 4000 байт на строку и настройками системных параметров можно его растянуть хотя-бы в 32 килобайта.

Тем более что в поля все чаще кладут semi-structured информацию (JSON/XML e.t.c).

Но вы можете их использовать просто как констрейнт чтобы акцентировать внимание что поле имеет особый вид строки. Например хеш SHA-256 или какой-то ключ или UUID.

Поддерживаю Дмитрия в наблюдении за oversized attribute.
Ответ написан
Комментировать
tsklab
@tsklab
Здесь отвечаю на вопросы.
Столкнулся с ситуацией, что 128 символов для одной колонки стало недостаточно
VARCHAR(255) — скорость не изменится.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы