Тип данных Unicode в SQL
Я новичок в Microsoft SQL. Я планирую сохранить текст на сервере Microsoft SQL, и в нем будут специальные международные символы. Есть ли «Тип данных»? специфично для Unicode или я лучше кодирую свой текст со ссылкой на номер Unicode (т.е. \ u0056)
Ответы на вопрос(4)
базы данных, и если в вашей базе данных есть сопоставление Unicode, строки внутри таблиц имеют Unicode. Также для строковых столбцов вы должны использоватьnvarchar или жеnchar типы данных, чтобы они могли хранить строки Unicode. Но эта функция работает, если ваша база данных имеет набор символов или параметры сортировки utf8 или unicode. Прочитайте эту ссылку для получения дополнительной информации.Юникод и SQL Server
чтобы заставить Юникод при манипулировании данными вставки.
INSERT INTO <table> (text) values (N'<text here>)
Nvarchar/Nchar (MSDN ссылка). Раньше былNtext тип данных, но в настоящее время он устарел в пользуNvarchar.
Столбцы занимают вдвое больше места по сравнению с аналогами не-Unicode (char а такжеvarchar).
Затем, когда «вручную» вставляя в них, используйтеN чтобы указать его Unicode-текст:
INSERT INTO MyTable(SomeNvarcharColumn)
VALUES (N'français')
что вы имеете в виду? Если специальные средства означают, что они не являются общими и случайными, тогда издержки nvarchar могут не иметь смысла в вашей ситуации для таблицы с очень большим числом строк или большим количеством индексаций.
Я полностью согласен с использованием Юникода, но важно понимать, когда это уместно.
Если вы смешиваете данные с разными подразумеваемыми кодовыми страницами (на японском и китайском в одной базе данных) или просто хотите ориентироваться на интернационализацию и локализацию, то вы хотите, чтобы столбец был Unicode и использовал тип данных nvarchar, и это прекрасно хорошо. Юникод не собирается волшебным образом решать все проблемы сортировки для вас.
Если вы знаете, что вы всегда будете хранить в основном ASCII, но некоторые случайные иностранные символы, просто сохраните ваши данные UTF-8 или данные в кодировке HTML в varchar. Если все ваши данные на японском языке и кодовая страница 932 (или любая другая отдельная кодовая страница), вы все равно можете хранить двухбайтовые символы в varchar, они по-прежнему занимают два байта. Я хочу сказать, что когда вы уже находитесь в сопоставлении DBCS, международные символы больше не являются "специальными". Это не только хранилище данных, но и любые индексы, а также рабочий набор при работе с таким столбцом в запросах и в других потоках данных.
И не устанавливайте общее правило, согласно которому все символьные данные должны быть nvarchar - это пустая трата для многих столбцов, которые являются кодами или идентификаторами.
Каждый раз, когда у вас есть колонка, задавайте те же вопросы:
Какой тип данных?
Какой диапазон?
Допускаются ли значения NULL?
Каков предел размера?
Есть ли какие-либо ограничения, которые я должен применить сейчас, чтобы прекратить ввод плохих данных с самого начала?