Depolama ve performans üzerindeki etkileri için Unicode
SQL Server ucs-2 kodlama düzeni kullanarak Unicode verileri depolar.Bu mekanizma altında 2 bayt kullanarak tüm Unicode karakterler depolanır.
Arasında Unicode ve Unicode olmayan karakter veri depolamak, fark olup Unicode olmayan veri çift baytlık karakter kümesi kullanılarak saklanan üzerinde bağlıdır.Tüm Doğu Asya dilleri ve Tay dili tek bayt Unicode olmayan karakterleri saklar.Bu nedenle, bu dilleri Unicode saklamak Unicode olmayan kod sayfa belirlemek için kullanılan iki kez alan kullanır.Diğer taraftan, birçok Asya dilleri Unicode olmayan kod sayfaları karakter depolama çift baytlı karakter kümesi (dbcs) belirtin.Bu nedenle, bu dillere ait neredeyse hiçbir depolama arasındaki farkı olmayan-Unicode ve Unicode yoktur.
Aşağıdaki tablo olmayan-Unicode karakter veri depolama çift baytlık karakter kümeleri belirtin kod sayfaları gösterir.
Dil |
Kod sayfa |
|---|---|
Basitleştirilmiş Çince |
936 |
Geleneksel Çince |
950 |
Japanese |
932 |
Kore Dili |
949 |
Unicode verilerini performans üzerindeki etkisini çeşitli şunlardır etkenlere göre karmaşık:
Unicode sıralama kurallarını ve sıralama kurallarını Unicode olmayan arasındaki fark
Çift baytlı ve tek baytlık karakter sıralama arasındaki fark
istemci ve sunucu arasında kod sayfa dönüştürme
sql Server Unicode olmayan veri Windows ile tanımlandığı Dize karşılaştırmaları gerçekleştiren harmanlama Unicode kullanarak sıralama kuralları.Bu kurallara göre sıralama kurallarını Unicode olmayan çok daha karmaşık olduğu için bunlar daha kaynak yoğundur.Bu nedenle, Unicode sıralama kuralları sık sık daha pahalı olmakla birlikte, genellikle çok az arasında fark yoktur performans Unicode veri ve Unicode olmayan veri Windows ile tanımlandığı harmanlama.
sql Server Unicode olmayan sıralama kurallarını kullanıyorsa, yalnızca sql kullanarak tanımlanan Unicode olmayan veri üzerinde olduğu harmanlama.Bu taramaları ve sıralama örnek uyguladığınızda Unicode sıralama kurallarına göre genellikle daha hızlıdır.Unicode sıralama kuralları Uygula kullanarak tanımlanan tüm Unicode verilerini bir Windows harmanlama veya sql harmanlama.
Çift bayt cinsinden veri depolandığından ikincil önemini çok fazla Unicode veri sıralama Unicode olmayan veri yavaş olabilir.dbcs veri Unicode karakter sabit genişlikli ederken tek bayt ve çift baytlı genişlikleri, aslında bir karışımını olduğundan diğer taraftan, Asya karakterleri Unicode sıralama belirli bir kod sayfa, Asya dbcs verileri sıralama daha hızlıdır.
Diğer performans sorunları öncelikle sorun kodlama mekanizması arasındaki dönüştürme belirlenir bir örnek , sql Server ve istemci.Genellikle, istemci/sunucu kod sayfa dönüştürme performans üzerindeki etkileri ihmal edilebilir.Yine de, bu katmanda ortaya çıkmasını anlamanız gerekir.
odbc API, 3.6 veya önceki bir sürüm ve db Kitaplığı API Unicode tanımaz.Bu API'leri tarafından tanımlanan veri erişim yöntemleri kullanan istemciler için kaynakları örtülü olarak Unicode verileri istemci kod sayfa dönüştürmek için kullanılır.Ayrıca, yapıldığında istemci tarafında veri bozulması riskini istemci kod sayfa belirli Unicode karakterlerini tanımaz.
odbc Microsoft Data Access Components 2.7 sürümü sql Server sürüm 7.0 ve ole db ve ado ile birlikte başlayarak, sonraki sürümleri Unicode farkında olarak ve ucs-2 kodlama mekanizması varsayalım.Bu nedenle, uygulama Unicode etkinse, dönüştürme sorun bulunmamaktadır, kesinlikle bir sql Server örnek Unicode verilerle çalışırken.Ancak veri depolama düzeneği Unicode özellikli bir API kullanan bir istemci, örnek sql Server Unicode, dönüştürme sorun yok.Ancak, herhangi bir veri eklediğiniz bir riski yoktur veya herhangi bir karakter için kod noktaları sql Server kod sayfa eşlediyseniz güncelleştirme işlemlerini bozulmuş.
Unicode en iyi yöntemler
Unicode genellikle bir depolama ve ne kadar sıralama hakkında etkileri bilincini tarafından saptanan dbcs olmayan verileri depolamak için dönüştürme ve olası veri bozulması verilerle istemci etkileşimler sırasında meydana olup olmadığını karar verme.Sıralama ve dönüştürme gerçekleşeceği yeri üzerinde performansı etkileyebilir.Ancak, çoğu uygulama için etkisi ihmal edilebilir olmasıdır.İyi tasarlanmış dizinler veritabanlarıyla etkilenmesi özellikle bunlar.Ancak, veri bozulması etkiler sadece bütünlük , uygulama ve veritabanı, aynı zamanda bir bütün olarak iş.Aşağıdakilerin her ikisi de doğruysa bu dengelemeyi içinde belirli bir kod sayfa karakter verileri depolamak anlamlı olabilir:
Depolama alanı tasarrufu, donanım kısıtlamaları nedeniyle çıkıştır.Veya, veri çok sayıda, sık sık sıralar gerçekleştirdiğiniz ve sınama Unicode depolama düzeneği performansı önemli ölçüde etkiler gösterir.
Tüm istemciler bu verilere erişme kod sayfaları etiketlerinize uygun ve bu durum beklenmedik biçimde değişmez emin olabilirsiniz.
Çoğu saat, karakter verileri depolamak için karar bile dbcs olmayan veri Unicode daha performans yerine iş gereksinimlerine göre temel almalıdır.Internet trafiğinin hızlı büyüme teşvik global ekonomide, farklı çalıştıran istemci bilgisayarları desteklemek için her zamankinden çok daha önemli durumundadır.Ayrıca, tek bir çekme giderek daha zor gelmektedir kod sayfa dünya çapında bir izleyici tarafından gerekli tüm karakterleri destekler.