Neden hala varchar veri tipi var?

Veri tabanlarımın çoğunda varchars olarak tanımlanan alanlar var. Amerika'da yaşadığım ve çalıştığım için bu çok problem olmamıştı (var olan tek dilin "Amerikan" olduğu. Ahem )

Yaklaşık 5 yıl veritabanları ile çalıştıktan sonra, nihayetinde varchar alanının sınırlı doğası ile ilgili problemler yaşadığımı ve verileri nvarchar olarak depolamak için alanlarımı değiştirmek zorunda kaldığımı gördüm. Bir tabloya başka bir güncelleme yapmak zorunda kaldıktan sonra, bir varchar alanını nvarchar'a dönüştürmekle ilgili düşündüm, neden hala bu şekilde yapıyoruz? O zamandan beri, ders kitaplarımın hepsini 10 yıl önce okuldayken yaptığım ders kitaplarından varchar yerine nvarchar yerine nvarchar olarak tanımlamaya karar verdim.

2011 ve geçtiğimiz yıl SQL Server'ın yeni bir sürümü oldu. Nvarchar kullanıyorken / kullanmamız gerektiğinde neden bir varchar veri tipini desteklemeye devam ediyoruz?

Sıklıkla nvarcharların varcharlardan "iki kat daha büyük" olduğunu savunduğunu biliyorum, bu nedenle depolama alanı kullanımı varkarları kısmak için tek bir tartışma olabilir.

Ancak, bugünün kullanıcıları, depolama alanından tasarruf etmek istiyorlarsa, verileri varsayılan UTF-16 yerine UTF-8 olarak depolamak için nvarchar'larını tanımlayabilirler. Bu, öncelikli olarak istenirse 8 bitlik kodlamaya izin verirken, DB'lerine eklenen nadir 2-8 baytlık karakterin hiçbir şeyi bozmayacağına dair güvence verir.

Bir şey mi eksik? Bunun son 15-20 yılda değişmemesinin iyi bir nedeni var mı?

1. Varchar çalışması, bazı harmanlama sorunlarına bağlı olarak, pek çok Batı Avrupa dili (Norveççe, Danimarkaca, Almanca, Fransızca, Hollandaca vb.) için yeterince iyi.

2. Buna bakınız SO varchar vs nvarchar performance nvarchar'in ciddi performans etkileri var

3. Bu, MDY ile DMY arasındaki tarihlerle karşılaştırıldığında önemsizdir.

Standartlara ve uyumluluğa yönelik cevapların yanı sıra, performans da akılda tutulmalıdır. Disk alanı kolayca ucuz olarak kabul edilirken, DBA'lar / Geliştiriciler genellikle sorgu performansının doğrudan bir tablonun satır / sayfa boyutuyla ilgili olduğu gerçeğini göz ardı eder. (Gerekmediğinde) NVARCHARyerine kullanmak VARCHAR, karakter alanlarınız için satır boyutunu etkili şekilde iki katına çıkarır. 5 veya 10 adet 50 uzunluğa sahip alanınız varsa, potansiyel olarak her satıra 500 bayt daha eklemek isteyebilirsiniz. Geniş bir tablonuz varsa, bu her satırı birden çok sayfaya iter ve performansı olumsuz yönde etkiler.

Çok sayıda kuruluşun, tek baytlık karakterleri üstlenen geniş bir uygulama, arayüz, platform ve araç tabanı vardır. Veritabanları nadiren izolasyon halinde yaşar - bunlar bir BT ekosisteminin bir parçasıdır. Tek baytlık karakterlere bağlı binlerce bileşene ve milyonlarca kod satırına sahipseniz, unicode'a geçmek için gereken zamana ve paraya yatırım yapmak için iyi bir nedene ihtiyacınız olacaktır. Bu ölçekte değişikliklerin tamamlanması yıllar alabilir. Bazı yerlerde Unicode hala nispeten yeni, nadir veya tam olarak desteklenmiyor.

VARCHAR ve NVARCHAR, ISO Standard SQL'in bir parçasıdır. SQL Server'da VARCHAR desteğinin kaldırılması veya kaldırılması uyumluluk ve taşınabilirlik açısından geriye doğru bir adım olacaktır.

Alternatif olarak, bugünün kullanıcıları, depolama alanından tasarruf etmek istiyorlarsa, verileri varsayılan UTF-16 yerine UTF-8 olarak depolamak için nvarchar'larını tanımlayabilirler.

Bu tam olarak çoğu açık kaynaklı veritabanının yaptığı şeydir VARCHAR.

• MySQL sağlar utf8ve ucs2"alfabe".
• SQLite size UTF-8 (varsayılan) ve UTF-16 arasında bir seçenek sunar.
• PostgreSQL UTF-8'i destekler (ancak UTF-16'yı değil).

İki ayrı dize türüne gerek yok.

Microsoft, 8 bit dizelerin eski kodlamalar ve Unicode = UTF-16 için olduğu görüşünde gariptir. Muhtemelen Windows API ile kendisi charve wchar_tbu şekilde muamele ile ilgilidir .

Çünkü bazılarımız, Unicode yeteneklerine ihtiyaç duymayan, en az gelişmiş donanımdan daha küçük uygulamalar için daha hafif, daha küçük uygulamalar oluşturuyoruz. Belki daha sonra değiştirmemiz gerekecek, ama şimdilik, sadece ihtiyacımız yok. Dizelerimin, NVARCHAR'ın altında olması gereken alanı 1/2 almaları hoşuma gidiyor.