Depolama ve Unicode, performansı etkiler.
SQL Server UCS-2 kodlama düzeni'ni kullanarak, Unicode verileri depolar.Bu mekanizma altında 2 bayt kullanarak, tüm Unicode karakterler depolanır.
Fark arasında Unicode ve Unicode karakter verilerinin depolanacağı yer olup olmadığını Unicode olmayan veri çift baytlı karakter kümesi kullanılarak saklanan üzerinde bağlıdır.Unicode karakterler, tüm Doğu Asya dilleri ve Tay dili tek bayt cinsinden depolar.Bu nedenle, bu dil, Unicode olarak depolamak, bir Unicode kod sayfa belirlemek için kullanılan iki kez alanı kullanır.Öte yandan, birçok Asya dilleri, Unicode kod sayfaları çift baytlı karakter kümesi (DBCS) karakter depolama belirtin.Bu nedenle, bu dillere ait neredeyse hiçbir depolama arasındaki farkı Unicode ve Unicode yoktur.
Aşağıdaki tabloda olmayan-Unicode karakter veri depolama, çift baytlı karakter kümelerinde belirlediğiniz kod sayfalarını gösterir.
Dil |
Kod sayfa |
|---|---|
Basitleştirilmiş Çince |
936 |
Geleneksel Çince |
950 |
Japanese |
932 |
Kore Dili |
949 |
Unicode verilerini performans üzerindeki etkisini çeşitli aşağıdakileri içeren tarafından karmaşık:
Unicode sıralama kurallarını ve sıralama kurallarını Unicode arasındaki fark
Çift bayt ve tek baytlık karakter sıralama arasındaki fark
istemci sunucu arasında kod sayfa dönüştürme
SQL Server Unicode sıralama kurallarını kullanarak, bir Windows harmanlaması ile tanımlanan Unicode olmayan veri dize karşılaştırmaları gerçekleştirir.Bu kurallar, Unicode olmayan sıralama kurallarına göre çok daha karmaşık olduğundan, daha fazla kaynak yoğun kullanılırlar.Bu nedenle, Unicode sıralama kurallarına genellikle daha pahalıdır, ancak genellikle küçük arasında fark yoktur performans Unicode verilerini ve bir Windows ile tanımlanan Unicode olmayan veri harmanlama.
SQL Server Unicode sıralama kurallarını kullanır, yalnızca SQL kullanarak tanımlanan Unicode verileri olduğu harmanlama.Sıralar ve bu taramaları örnek uyguladığınızda Unicode sıralama kurallarına göre genellikle daha hızlıdır.Bir Windows harmanlaması veya bir SQL Harmanlaması'nı kullanarak tanımlanan tüm Unicode verilerini Unicode sıralama kurallarını uygulayın.
Çift bayt olarak depolanan verileri ikincil önemini Unicode verileri çok sayıda sıralama Unicode olmayan veriler yavaş olabilir.Unicode karakterler, sabit genişlikli çalışırken DBCS veri tek bayt) ve iki baytlık genişliği, gerçekte bir karışımını diğer taraftan, Asya Unicode karakter sıralama, belirli bir kod sayfa Asya DBCS verileri sıralama çok hızlı dizinidir.
Diğer performans sorunları, SQL Server örneğini ve istemci arasındaki bir kodlama mekanizması dönüştürülmesinden sorun öncelikle belirler.Genellikle, kod sayfa dönüştürme istemci/sunucu performans üzerindeki etkileri gözardı.Yine de, bu katmanda oluşup anlamalısınız.
ODBC API 3.6 veya önceki sürüm ve DB Kitaplığı API Unicode tanımaz.Bu Apı'leri tarafından tanımlanan bir veri erişim yöntemlerini kullanan istemciler, kaynaklar örtülü olarak Unicode verilerini, istemci kod sayfa dönüştürmek için kullanılır.Ayrıca, bir riski yoktur, istemci tarafında veri bozulması istemci kod sayfa, belirli Unicode karakterler algılamazsa.
ODBC Microsoft Data Access Components 2.7 SQL Server sürüm 7.0 ve OLE DB ve ADO ile gelen sürüm ile başlayarak, sonraki sürümlerinde duyarlı Unicode; UCS-2 bir kodlama mekanizması varsayalım.Bu nedenle, uygulama Unicode etkinleştirilmişse, dönüştürme sorun bulunmamaktadır, kesinlikle bir SQL Server örnek Unicode verilerle çalışırken.Bir istemci bir Unicode özellikli APı'SI kullanıyor, ancak Unicode verilerini depolama düzeneği, SQL Server örnek değil, dönüştürme bir sorun bulunmamaktadır.Ancak, tüm verileri bir riski yoktur veya herhangi bir karakter için kod noktaları, SQL Server kod sayfa eşlenemez, güncelleştirme işlemlerini bozulmuş.
Unicode en iyi yöntemler
Unicode genellikle bir tanıma etkileri hakkında ne kadar sıralama ve depolama birimindeki tarafından belirlenen şekilde, olmayan DBCS verileri depolamak için , dönüştürme ve olası veri bozulması sırasında verilerin istemci etkileşimlerinin gerçekleşmesi mi karar verme.Sıralama ve dönüştürme gerçekleşeceği yeri bağlı olarak performansı etkileyebilir.Ancak, çoğu uygulama için gözardı sahiptir.Iyi tasarımlanmış dizinleriyle etkilenip etkilenmedikleri özellikle olası veritabanlarıdır.Ancak, veri bozulması, yalnızca bir uygulama ve veritabanı, aynı zamanda bir bütün olarak iş bütünlüğünü etkileyecektir.Aşağıdakilerin her ikisi de doğruysa, bu dengelemeyi considering içinde belirli bir kod sayfa karakter veri saklama anlamlı olabilir:
Depolama alanı tasarrufu, donanım kısıtlamaları nedeniyle çıkıştır.Veya, tür veri çok sık gerçekleştirdiğiniz ve sınama gösteren bir Unicode depolama düzeneği performansı önemli ölçüde etkiler.
Kod sayfalarının tüm istemcilerin bu verilere sizden eşleştirmek ve bu durum beklenmedik bir şekilde değişmez emin.
Çoğu saat, karakter veri depolamak için karar bile olmayan DBCS verilerde, Unicode fazla iş gereksinimlerini yerine, performans temel.Hızlı ınternet trafiğini büyüme teşvik genel Ekonomi, bunu her zamankinden farklı yerel ayarlar çalıştıran istemci bilgisayarları desteklemek için çok önemli olma.Ayrıca, dünya çapında bir izleyici tarafından gerekli olan tüm karakterleri destekleyen tek bir kod sayfa seçmek giderek daha zor olma.