Зачем указывать длину для символов разных типов
ссылаясь на документацию Postgres на Типы Символов, Я неясен в вопросе указания длины для типов символов, изменяющихся (varchar).
предположения:
- длина строки не имеет значения для приложения.
- вам все равно, что кто-то помещает этот максимальный размер в базу данных
- у вас есть неограниченное пространство на жестком диске
все это:
в требование хранения для короткой строки (до 126 байт) составляет 1 байт плюс фактическая строка, которая включает пробел в случае характера. Более длинные строки имеют 4 байта вместо 1. Длинные строки сжимаются системой автоматически, поэтому физическая потребность на диске может быть меньше. Очень длинные значения также хранится в фоновых таблицах, чтобы они не мешали rapid доступ к более коротким значениям столбцов. В любом случае, как можно дольше характер строка, которая может быть сохранена, составляет около 1 ГБ. (Максимальное значение это будет разрешено для N в объявлении типа данных меньше, чем что. Было бы не полезно изменить это, потому что с multibyte кодировки символов количество символов и байтов может быть достаточно отличающийся.
Это говорит о размере строки, а не о размере поля (т. е. похоже, что он всегда будет сжимать большую строку в большом поле varchar, но не маленькую строку в большом varchar поле?)
Я задаю этот вопрос, поскольку было бы намного проще (и лениво) указать гораздо больший размер, поэтому вам никогда не придется беспокоиться о слишком большой строке. Например, если я укажу varchar(50) для имени места, я получу места, которые имеют больше символов (например, Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch), но если я укажу varchar(100) или varchar(500), я меньше похож на эту проблему.
Итак, вы получите хит производительности между varchar(500) и (произвольно) varchar(5000000) или text (), если ваша самая большая строка была длиной 400 символов?
также из интереса, если у кого-то есть ответ на это и знает ответ на это для других баз данных, добавьте это тоже.
я погуглил, но не нашел достаточно техническое объяснение.
4 ответов
Я понимаю, что наличие ограничений полезно для данных целостность, поэтому я использую размеры столбцов как для проверки элементов данных на нижнем уровне, так и для лучшего описания модели данных.
ссылки по теме:
Я понимаю, что это наследие старых баз данных с хранилищем, которое не было таким гибким, как у Postgres. Некоторые будут использовать структуры фиксированной длины, чтобы упростить поиск конкретных записей, и, поскольку SQL является несколько стандартизированным языком, это наследие все еще видно, даже когда оно не дает никакой практической пользы.
таким образом, ваш подход" сделать его большим " должен быть полностью разумным с Postgres, но он не может хорошо переноситься на другие менее гибкие Системы РСУБД.
документация объясняет это:
Если переменный символ используется без спецификатора длины, тип принимает строки любого размера. Последнее является расширением PostgreSQL.
стандарт SQL требует спецификации длины для всех его типов. Это, вероятно, в основном по причинам наследия. Среди пользователей PostgreSQL предпочтение, как правило, опускает спецификацию длины, но если вы хотите написать переносимый код, вы должны включить его (и выбрать произвольный размер, во многих случаях).
еще две мысли:
документ Postgres говорит ,что "очень длинные значения также хранятся в фоновых таблицах". Таким образом, определение всех строк как неограниченных, вероятно, толкает их в фоновые таблицы-наверняка хит производительности.
объявление всего как очень долго мешает усилиям БД предсказать план выполнения запроса, потому что у него меньше знаний о данных.
построение b-дерева для хранения индекс также будет сброшен, потому что он не сможет угадать разумную стратегию упаковки. Например, если бы пол был текстом, как бы вы узнали, что все это только M или F?