SQL / WINDOWS - оптимальная длина символа - имеет значение

Question

Три маленьких вопроса для умных людей stackoverflow ....

WINDOWS:

• максимальная длина имени файла в Windows 255 - почему это, а почему не 256?

• почему максимальное полное имя файла (полный путь) указано как 32 767 когда на самом деле это должно быть максимум 255/260, чтобы избежать ошибок.

SQL:

• при создании полей chars или varchars в sql влияет ли указанная вами длина на производительность. Пример: 256 Varchar работает лучше, чем 260 или 4096 лучше, чем 4000?

Спасибо за любую помощь.

Answer 1

1) см. Ответ Чарльза выше

2) давай сейчас. это слишком просто. Путь! = Имя файла

3) Важна связь между размером страницы и размером записи. Если вы используете varchars и у вас много изменений данных, когда поля изменяются от коротких до длинных, SQL тратит время на перемещение записей на разные страницы. Если ваши поля символов очень длинные, и на страницу помещается не так много записей, это может немного снизить производительность. Если длина данных сильно варьируется, varchars будет лучше использовать пространство для хранения. И у них нет тех досадных пробелов в конце ваших данных, которые вы должны обрезать все время.

Answer 2

Раньше было максимум 255, потому что это максимальное значение, которое 1-байтовое (8-битное) число без знака может представлять 11111111 = 255. Чтобы получить 256, нужно иметь 9 бит (1). 0000 0000)

Что касается второй части, я не уверен, но вопрос sql: раньше это было проблемой гораздо большей, чем сегодня, то, что вы указали, контролировало максимальный размер каждой строки данных, и ядро ​​базы данных должно было бы выделить достаточно места для каждой строки, чтобы иметь возможность хранить это максимум. Таким образом, введенные вами значения влияют на то, сколько места было выделено на диске для каждой записи, и, следовательно, также влияют на максимальное количество записей на «страницу» дискового пространства ... Чем меньше записей на странице, тем больше операций ввода-вывода диска требуется получить любое конкретное количество записей ... Поскольку дисковый ввод-вывод является определяющим фактором в производительности базы данных, это оказало значительное влияние.

В настоящее время, однако, современные системы СУБД закодированы для оптимизации этой проблемы, я думаю, путем динамического управления тем, сколько записей фактически хранится на странице, на основе данных, которые фактически находятся в записи, а не на указанных вами максимумах .

Answer 3

Байт 0 = длина, 8 бит без знака, поэтому допускается 255 символов. Ноль = пустая строка. Остальные 255 - это предел 255.

char (4000) очень отличается от char (10). SQL Server всегда дополняет данные, если они не равны нулю.

Нет разницы между varchar (4000) и varchar (10), если только вы не хотите индексировать его, где у вас есть ограничение 900 байт

SQL Server до 7 имел ограничение varchar 255 и отсутствие поддержки юникода. Это была боль ...

Answer 4

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

В то время как оболочка Windows имеет максимальный путь 255 символов, файловая система NTFS фактически поддерживает имена файлов до 32 000 символов для совместимости с UNIX.

Обычно легко подделать оболочку Windows и обмануть ее, чтобы сохранить пути / имена файлов, длина которых превышает 255 символов. Например, сопоставление диска или совместное использование папки.

Я обсуждаю это более подробно в этом посте на 256-символьных имен файлов должно быть достаточно для всех .

Answer 5

Есть 256 возможных значений, потому что последовательность начинается с нуля:)

Answer 6

CHAR имеет фиксированную длину и будет принимать именно то, что вы указываете как длину, независимо от того, заполняете вы ее или нет.

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

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

Answer 7

varchar (256) будет работать так же, как varchar (8000) или varchar (5) Они хранятся одинаково ... (в MS SQL Server)

Answer 8

SQL Server 2000 имеет жесткое поле размером 8 КБ, ограничение размера страницы и строки. В SQL Server 2005+ ограничение в 8 КБ для страниц и полей по-прежнему применяется, но строки могут переполняться (что, конечно, пагубно сказывается на производительности).

Мне сказали несколько администраторов баз данных, что идеальные размеры строк должны быть делителями 8 КБ, хотя ни один из них никогда не мог объяснить, как точно рассчитать размеры строк.