En büyük endişe, nvarchar
karakter başına 2 bayt, oysa 1 varchar
kullanır. Bu nedenle, * ile nvarchar(4000)
aynı miktarda depolama alanı kullanır varchar(8000)
.
İki kat fazla depolama alanına ihtiyaç duyan tüm karakter verilerinize ek olarak, bu ayrıca:
nvarchar
Satırları 8060 bayt satır sınırı / 8000 bayt karakter sütun sınırı içinde tutmak için daha kısa sütunlar kullanmanız gerekebilir .
nvarchar(max)
Sütun kullanıyorsanız , satırdan daha erken bir şekilde kullanılmazlar varchar(max)
.
nvarchar
900 baytlık dizin anahtarı sınırı içinde kalmak için daha kısa sütunlar kullanmanız gerekebilir (neden bu kadar büyük bir dizin anahtarı kullanmak isteyeceğinizi bilmiyorum, ama asla bilmiyorsunuz).
Bunun yanında, nvarchar
istemci yazılımınızın Unicode ile çalışmak üzere oluşturulduğunu varsayarak çalışmak çok da farklı değil. SQL Server şeffaf bir varchar
şekilde bir a çevirir nvarchar
, bu nedenle değişmezde 2 baytlık (yani Unicode) karakterleri kullanmıyorsanız, dize değişmezleri için N önekine kesinlikle ihtiyacınız yoktur. Döküm unutmayın nvarchar
için varbinary
aynı yapmaktan daha verim farklı sonuçlar varchar
. Önemli olan nokta, uygulamanın çalışmasını sağlamak için sürecin kolaylaştırılmasına yardımcı olan her varchar kelimesini hemen bir nvarchar literaline değiştirmek zorunda kalmayacağınızdır.
Veri sıkıştırma kullanırsanız * (hafif satır sıkıştırma yeterlidir, Enterprise Edition gerekli SQL Server 2016 SP1 önce genellikle bulacaksınız) nchar
ve nvarchar
daha fazla yer kaplar char
ve varchar
nedeniyle, (SCSU algoritmasını kullanarak) Unicode sıkıştırma .