Есть ли разница в БД Postgres: хранить string(255) или string?

Question

[LakeForest]

Я понимаю, что в одном случае длина строки ограничена, в другом нет (это классы из AlchemySQL Python).
На парах изучал Oracle, и нам рассказывали, что если мы не будем задавать кол-во символов, то в итоге может иметь просадку по производительности БД.
Но сейчас пытаюсь найти эквивалетно ли данное утверждение для Postgres и нашел только такое:

Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

То есть в postgres-е ограничение длины влияет только на объем, занимаемой памяти, созданной базы (каждая колонка String будет весить 1 Гб и состоять в большинстве своем из пробелов)?
Или я неправильно понимаю?
Все равно лучше вообще не ограничивать??

Comments

[kalapanga]

По-моему, в вопросе два сравнения смешаны.
1) Ограниченная строка (char(n), varchar(n)) vs неограниченная (text, varchar)
2) Строки постоянной длины (char(n)) vs переменной длины (varchar(n))
Какой именно момент интересует? Если второй, то сейчас вроде как смысла использовать char(n) практически нет, только место занимает и в принципе требуются лишние действия для работы с ним. Если первый, тут пусть специалисты поопытней напишут.

Пустая колонка не будет весит 1ГБ. Там речь о том, что даже "неограниченная" строка всё-таки ограничена одним гигабайтом.

[LakeForest]

kalapanga, так, издалека: я пишу ORM с помощью sqlalchemy, там есть тип данных String.
Как я вижу колонки с типами String(255) создали в БД колонки с типами varchar(255).
Я пытаюсь понять с т.з. postgres-а есть ли какой-нибудь профит указывать ограничение в длине или нет? Вообще хоть какой-нибудь же должен быть? Или это профит будет заметен только при переносе базы данных в другую СУБД?

[kalapanga]

LakeForest, а просто "string" какую колонку создаёт? text ?
В любом случае эти типы хранят строки как есть. Т.е. по занимаемому месту никакого перерасхода не будет. Ограничение на длину, на мой взгляд, прежде всего смысловой характер носит. А то ведь если можно записать в поле "фамилия" гигабайт текста, то ведь и запишут!
Может тут ещё какие нюансы есть, люди допишут.

Answer 1

[Melkij]

Для начала, в postgresql нет типа данных string. (а если это самодельный тип, что postgresql сделать тоже позволяет, то смотреть надо как он реализован у вас)

Для текстовых данных в postgresql есть:
- text. Просто text, без специфических ограничений на содержимое
- varchar - это всё тот же самый text. К varchar можно добавить указание ограничения максимальной длины хранимого текста в символах. Почему это отдельный тип данных? Потому что такого требование стандарта SQL
- char - фиксированный длины (в символах! в байтах они всё равно динамической длины получатся для того же utf8). Смысла его использовать в postgresql, как вы сами процитировали документацию, нет. Зачем он нужен? Потому что описан в стандарте.

В отличии от, например, mysql, для postgresql нет ничего особого в значении 255. Если в определении таблицы видно такое ограничение на 255 символов - обычно это означает именно "никто не обдумывал цель такого ограничения для этого поля, просто какое-то число"

Говоря о выборе между text или varchar(N) - varchar(N) с разумным для этих данных N предпочтительнее для коротких строк, потому что не даст записать 10мб туда где должно быть, например, не более 64 символов (это не совсем шутка, случай из практики). А по ошибке в месте записи дебажить логику приложения куда как проще, чем искать потом откуда такое взялось.

Comments

[Vitsliputsli]

Спасибо, не знал, удалил свой ответ, чтобы не вводить в заблуждение.
Насчет char в PostgreSQL, поясните, пожалуйста, почему динамической длины? Разве он не зарезервирует сразу длину = n char X максимальную длину 1 char? А если он хранит строку как тип varchar, т.е. с отдельным хранением длины строки, зачем тогда хранить дополнительные пробелы, в выводе они понятное дело нужны, но зачем внутри их хранить?

[Melkij]

у char(N) число N измеряется в символах, но для, например, UTF8 1 символ занимает от одного до четырёх байт. Поэтому получается оригинальный оксюморон, что char(N) тип данных фиксированной длины (в символах) переменного размера (в байтах).
Почему пробелы для char действительно пишутся физически как часть данных - честно говоря не очень представляю. https://github.com/postgres/postgres/blob/REL_14_S... по коду проще было так, судя по всему. По крайней мере в 1995.