Зачем указывать длину для символов различных типов - PullRequest
13 голосов
/ 06 сентября 2011

Что касается документации Postgres по Типы символов , мне неясно, как указать длину для типов переменных символов (varchar).

Предположение:

  • длина строки не имеет значения для приложения.
  • вас не волнует, что кто-то поместит этот максимальный размер в базу данных
  • у вас неограниченное пространство на жестком диске

В нем упоминается:

Требование к памяти для короткой строки (до 126 байт) составляет 1 байт плюс фактическая строка, которая включает пробел в случае символа,Более длинные строки имеют 4 байта служебной информации вместо 1. Длинные строки сжимаются системой автоматически, поэтому физические требования к диску могут быть меньше.Очень длинные значения также хранятся в фоновых таблицах, чтобы они не мешали быстрому доступу к более коротким значениям столбцов.В любом случае самая длинная строка символов, которую можно сохранить, составляет около 1 ГБ.(Максимальное значение, которое будет разрешено для n в объявлении типа данных, меньше этого. Менять это было бы бесполезно, поскольку в многобайтовых кодировках число символов и байтов может быть совершенно другим.

Это говорит о размере строки, а не о размере поля (то есть звучит так, будто она всегда сжимает большую строку в большом поле varchar, но не маленькую строку в большом поле varchar?)

Я задаю этот вопрос, так как было бы намного проще (и ленивее) указать гораздо больший размер, чтобы вам никогда не приходилось беспокоиться о слишком большой строке. Например, если я укажу varchar (50) для названия местаЯ получу локации, в которых будет больше персонажей (например, Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch), но если я укажу varchar (100) или varchar (500), мне не так нравится эта проблема.

Поэтому вы получите удар по производительностимежду varchar (500) и (произвольно) varchar (5000000) или text (), если ваша самая большая строка была, скажем, 40Длина 0 символов?

Также не интересно, если у кого-то есть ответ на этот вопрос и он знает ответ на этот вопрос для других баз данных, пожалуйста, добавьте его тоже.

Я гуглил, но не нашелдостаточно техническое объяснение.

Ответы [ 4 ]

12 голосов
/ 06 сентября 2011

Насколько я понимаю, наличие ограничений полезно для целостности , поэтому я использую размеры столбцов для проверки элементов данных на нижнем уровне и для лучшего описания модели данных.

Некоторые ссылки по этому вопросу:

5 голосов
/ 06 сентября 2011

Насколько я понимаю, это наследие старых баз данных с хранилищем, которое было не таким гибким, как у Postgres.Некоторые из них используют структуры фиксированной длины, чтобы упростить поиск определенных записей, и, поскольку SQL является несколько стандартизированным языком, это наследие все еще просматривается, даже если оно не дает никакой практической выгоды.

Таким образом, вашПодход "сделай это по-крупному" должен быть вполне разумным с Postgres, но он может не очень хорошо переноситься на другие, менее гибкие системы СУБД.

3 голосов
/ 07 сентября 2011

Документация объясняет это:

Если используется изменение символов без спецификатора длины, тип принимает строки любого размера.Последнее является расширением PostgreSQL.

Стандарт SQL требует спецификации длины для всех его типов.Это, вероятно, в основном по наследственным причинам.Среди пользователей PostgreSQL предпочтение, как правило, заключается в том, чтобы не указывать длину, но если вы хотите написать переносимый код, вы должны включить его (и выбрать произвольный размер во многих случаях).

1 голос
/ 29 августа 2017

Еще две мысли:

  1. В документе Postgres говорится, что «очень длинные значения также хранятся в фоновых таблицах».Таким образом, определение всех строк как неограниченных, вероятно, толкает их в фоновые таблицы - наверняка снижение производительности.

  2. Объявление всего, что очень долго, мешает усилиям БД по прогнозированию плана выполнения запроса,потому что у него меньше знаний о данных.

  3. Создание b-дерева, содержащего индекс, также будет отброшено, поскольку оно не сможет угадать разумную стратегию упаковки.Например, если бы пол был ТЕКСТОМ, как вы узнали бы, что все это только М или Ж?

...