varchar (255), varchar (256), nvarchar (255), nvarchar (256), nvarchar (max) и т.д.
256 похоже на приятное, круглое, эффективное пространство. Но я видел, что он использовал много. Почему?
Какая разница между varchar и nvarchar?
VARCHAR (255). Он не будет использовать все 255 символов хранилища, а именно необходимое хранилище. Он 255, а не 256, потому что тогда у вас есть место для 255 плюс нулевой терминатор (или размерный байт).
"N" для Unicode. Используйте, если вы ожидаете символов, отличных от ASCII.
В MS SQL Server (7.0 и выше) данные varchar представлены внутри с тремя значениями:
Важной частью является двухбайтовый индикатор длины данных. Если это был один байт, вы могли только правильно записать строки длиной от 0 до 255; с двумя байтами, вы можете записывать строки длиной 0 в нечто более 64000+ (в частности, 2 ^ 16 -1). Тем не менее, длина страницы SQL Server составляет 8 тыс., Из которой следует ограничение на 8000+ символов. (Там переполнение данных в SQL 2005, но если ваши строки будут такими длинными, вы должны просто пойти с varchar (max).)
Итак, независимо от того, как долго вы объявляете свой столбец данных varchar (15, 127, 511), то, что вы на самом деле будете хранить для каждой строки:
Который меня доводит до меня: несколько старых систем использовали только 1 байт для хранения длины строки и ограничивали вас максимальной длиной в 255 символов, что не так долго. С 2 байтами у вас нет такого произвольного предела... и поэтому я рекомендую выбрать номер, который имеет смысл для (предполагаемого нетехнического ориентированного) пользователя., Мне нравится 50, 100, 250, 500, даже 1000. Учитывая, что база из 8000 + байтов памяти, 255 или 256 так же эффективна, как 200 или 250, и менее эффективна, когда приходит время, чтобы объяснить вещи конечным пользователям.
Это относится к однобайтовым данным (т.е. ansii, SQL_Latin1 * _ * General_CP1, et al.). Если вам нужно хранить данные для нескольких кодовых страниц или языков с использованием разных алфавитов, вам нужно работать с типом данных nvarchar (который, я думаю, работает одинаково, два байта для числа charactesr, но для каждого фактического характера данных требуется два байта место хранения). Если у вас есть строки, которые могут превышать 8000 или более 4000 в nvarchar, вам нужно будет использовать типы данных [n] varchar (max).
И если вы хотите знать, почему так важно занимать пространство с дополнительными байтами, чтобы отслеживать, сколько времени находятся данные, посмотрите http://www.joelonsoftware.com/articles/fog0000000319.html
Филипп
При определении char/varchar и вариантов N есть несколько других моментов.
Во-первых, есть некоторые накладные расходы для хранения строк переменной длины в базе данных. Хорошим общим правилом является использование CHAR для строк длиной менее 10 символов, поскольку N/VARCHAR хранит как строку, так и длину, а также разницу между сохранением коротких строк в N/CHAR по сравнению с N/VARCHAR в 10 не стоит накладных расходов на длину строки.
Во-вторых, таблица на SQL-сервере хранится на страницах 8 КБ, поэтому максимальный размер строки данных составляет 8060 байт (остальные 192 используются для служебных данных SQL). Именно поэтому SQL допускает максимальный определенный столбец VARCHAR (8000) и NVARCHAR (4000). Теперь вы можете использовать VARCHAR (MAX) и версию Unicode. Но с этим могут возникнуть дополнительные накладные расходы.
Если я не ошибаюсь, SQL-сервер попытается сохранить данные на той же странице, что и остальная часть строки, но если вы попытаетесь поместить слишком много данных в столбец VARCHAR (Max), это будет относиться к нему как двоичный и сохранить его на другой странице.
Еще одно большое различие между CHAR и VARCHAR связано с разбиением на страницы. Учитывая, что SQL Server хранит данные на страницах 8 КБ, вы можете иметь любое количество строк данных, хранящихся на странице. Если вы ОБНОВЛЯЕТ столбец VARCHAR со значением, которое достаточно велико, чтобы строка больше не помещалась на странице, сервер разделит эту страницу, отведя некоторое количество записей. Если в базе данных нет доступных страниц, и база данных настроена на автоматическое увеличение, сервер сначала будет расширять базу данных, чтобы выделять ей пустые страницы, а затем выделять пустые страницы в таблицу и, наконец, разбивать одну страницу на две.
Если вы будете поддерживать языки, отличные от английского, вы захотите использовать nvarchar.
HTML должен быть в порядке, если он содержит стандартные символы ASCII. Я использовал nvarchar в основном в базах данных, которые были многоязычной поддержкой.
Поскольку есть 8 бит в 1 байт, и поэтому в 1 байте вы можете сохранить до 256 различных значений, которые
0 1 2 3 4 5 ... 255
Обратите внимание, что первое число равно 0, так что общее число 256.
Итак, если вы используете nvarchar (255), он будет использовать 1 байт, чтобы сохранить длину строки, но если вы опрокидываетесь на 1 и используете nvarchar (256), вы теряете 1 больше байта только для этого дополнительного 1 элемента с 255 (так как вам нужно 2 байта для хранения номера 256).
Это может быть не фактическая реализация SQL-сервера, но я считаю, что это типичная аргументация для ограничения вещей на 255 более 256 элементов.
и nvarchar для Unicode, которые используют 2 байта на символ и
varchar предназначен для обычного текста ASCII, который использует только 1 байт
IIRC, 255 - максимальный размер varchar в MySQL, прежде чем вам пришлось переключиться на текстовый тип данных, или был в какой-то момент (на самом деле, я думаю, что он выше сейчас). Поэтому, сохраняя его до 255, вы можете купить вам некоторую совместимость. Вы хотите посмотреть это, прежде чем действовать на него.
varchar vs nvarchar похож на ascii против unicode. varchar ограничен одним байтом на символ, nvarchar может использовать два. Вот почему вы можете иметь varchar (8000), но только nvarchar (4000)
Оба типа varchar и nvarchar для контента, но число, которое вы определяете при объявлении типа столбца, является максимальным.
Значения в "nvarchar" занимают в два раза больше места на диске/памяти как "varchar", потому что unicode является двухбайтным, но когда вы объявляете тип столбца, вы объявляете количество символов, а не байтов.
Поэтому, когда вы определяете тип столбца, вы должны определить максимальное количество символов, которые столбец когда-либо понадобится для хранения, и иметь это как размер varchar (или nvarchar).
Хорошее эмпирическое правило состоит в том, чтобы оценить максимальную длину sting, которую должен удерживать столбец, а затем добавить поддержку примерно на 10% больше символов, чтобы избежать проблем с неожиданно длинными данными в будущем.
varchar (255) также была максимальной длиной в SQL Server 7.0 и ранее.