В SQL Server 2008 R2 будет сжатие Unicode, см. Сжатие Unicode в SQL Server 2008R2 . Это сделает проблему пространства хранения nvarchar varchar в значительной степени проблемой прошлого. Вы все еще на SQL 2005, но вы должны программировать в будущем .
Вопрос varchar против nvarchar - это только одна сторона проблемы. Другим аспектом является обеспечение правильного сопоставления (необходимо для nvarchar так же, как для varchar). Поскольку столбцы не могут иметь несколько параметров сортировки, общее решение состоит в том, чтобы разделить данные на таблицы строк для каждого языка, где столбцы объявляются с соответствующим сопоставлением для каждого используемого языка.
Обновление
Продолжительное обсуждение международных данных SQL Server 2005 ведется по адресу Международные функции в Microsoft SQL Server 2005 . Кстати, комментарии типа «просто используй UTF-8» просто упускают смысл. SQL Server хранит данные nvarchar, закодированные как UCS-2, и все, точка. Вы можете хранить данные XML как UTF-8 или UTF-16, но ни один здравомыслящий специалист по базе данных не порекомендует использовать XML для хранения ваших строк.
Кроме того, хотя вы можете использовать кодировку , например, 1252, вам не так легко обойтись без единого сопоставления. Тем более, что у вас есть испанский как требование, и испанские сопоставления, как известно, проблематичны. Например, ваши говорящие по-испански пользователи будут ожидать, что «Chiapas» будет сортировать после «Colima», но латинская сортировка будет сортировать «Colima» после «Chiapas», см. Работа с сопоставлениями . При сравнении будут возникать другие проблемы, когда разные имена могут сравниваться, чтобы быть равными, опять же из-за неправильного выбора параметров сортировки.