veritabanı tasarımında fazla alan boyutunu abartma

Tablolarım için dizeler olan bazı alanlar var ve şu anda alan boyutunun çoğu oldukça yüksek karakter sınırlarına sahip. Örneğin, sokak adı için 100 karakter. Büyük tarla kullanımında ceza var mı? Örneğin, bu alan için sınırı 30 karakter olarak değiştirirsem, performans artışı veya boyutla verimlilik olur mu? Büzülmeye aday olabilecek yaklaşık 50 alan olacaktır.

Önerileriniz için teşekkürler.

Eğer hakkında konuşuyorsanız varcharve nvarcharsonra hayır ise, daha yüksek alan uzunluğuna izin vermenin cezası yoktur.

Yine de bazı uyarılar akılda tutulur:

• Değişken uzunluklu alanlar için (alan başına) satır başına 2 baytlık bir ek yük vardır . Çok kısa bir alanınız varsa a kullanmak daha mantıklı olabilir CHAR. Varchar(2)örneğin satır başına 2-4 bayt CHAR(2)kullanır , her zaman 2 kullanır.
• Çok uzun alanlar endekslenemez. Bir dizin anahtar kümesindeki tüm alanlar için maksimum uzunluk 900 bayttır.
• Beklediğinizden daha fazla veriye izin verirseniz, sonunda beklenmedik sonuçlar alırsınız. Bir sokak adı için 100 karaktere izin verirseniz, bir noktada başka verilerin farkında olmadan o alana girmesi muhtemeldir (örneğin tüm adres). Uygun şekilde boyutlandırdıysanız, bunun yerine insertte bir hata alırsınız.
• Çok geniş satırlara izin vermek sayfa bölünmelerine ve parçalanmaya yol açabilir. 8k'dan daha uzun bir satırınız varsa, birden fazla veri sayfasına bölünmesi gerekecektir. Bunların çoğu performansa gerçekten zarar verebilir. Genel olarak daha dar, daha verimlidir.

"Alan boyutunu gerçekten içinde depolanmış olan herhangi bir değerden daha büyük olarak bildirmek için bir ceza var mı?" Demek istiyorsanız, varchar olarak belirtildiği sürece cevap hayırdır. Bildiğim her SQL DB motoru, yalnızca verilerde verilen karakter sayısını (artı uzunluk değeri) depolar. Bu nedenle, alanı varchar (100) olarak tanımlar, ancak içine yalnızca 10 karakter depolarsanız, diskte yalnızca 10 karakter alır (artı uzunluk için 2 bayt veya daha fazla). Şüphe duyduğumda, varchar alanlarımı rutin bir şekilde gülünç hale getiriyorum.

"Uzun karakter alanlarını saklamanın bir cezası var mı?" Bugün disk alanı ucuz, ancak ücretsiz değil, bu yüzden hiçbir sebeple boşa harcamak istemezsiniz. Muhtemelen daha da önemlisi, verileri diskten okumak zaman alır, bu nedenle veri alanlarınız ne kadar uzun olursa program yavaşlar. Alan dizine eklenmişse, her okumanın anahtar değerini bu büyük uzun alanla karşılaştırması gerekeceğinden, bu durum alımlarınızı yavaşlatabilir.

Kullanıcıya büyük bir veri giriş alanı verirseniz, bunu er ya da geç kullanacaklarını unutmayın.

Bütün bunlar, çok küçük yerine çok büyük tarafında hata yapardım dedi. Disk alanı, kullanıcıları gerçek alana mevcut alana sığmayacakları için anında kısaltma yapmaya zorlamak istemediğiniz kadar ucuzdur. Bugün üzerinde çalıştığım sistemin, ürünlerimizin gerçek isimlerinin çoğu için çok küçük bir ürün açıklaması alanı var, bu yüzden kullanıcılar kısaltmak zorunda. Ve elbette her kullanıcı farklı şekilde kısalır, bu yüzden aynı şeyi söylemenin yirmi farklı yolu vardır.

Gerçekte tabloda depolanacak olandan daha büyük bir alan büyüklüğünü bildirmek için herhangi bir ceza olmadığını iddia eden herkes yanlıştır. Verilerin gerçek boyutu (artı 2 bayt ek yükü) gerçekte depolanan şeydir, ancak yürütme planı kadarıyla tahmini belirlemek için kullanılan sütun tanımıdır. Bu nedenle, 10 karakterlik bir değer depolamak için bir varchar (1000) bildirilirken, yalnızca 12 karakterlik disk alanı tüketilirken, yürütme planı tahminleri, hem operasyonu ne kadar bellek verecek kadar bellek hem de sonuçlar için çok daha az verimli ve olumsuz olacak. işlemin yalnızca bellekte gerçekleştirilip gerçekleştirilemeyeceği veya tempdb sürücü alanı gerektirip gerektirmeyeceği. Varchar (1000) sütununuzu oluşturabilirsiniz, ancak motor depolanan değerlerinizin gerçekten varchar (10) 'dan daha az olduğunu bilmez,

Alan uzunluğu kontrolü, 'ücretsiz' elde ettiğiniz bir şeydir, yani CHECKaynı şeyi yapmak için bir kısıtlama kullanmanız gerekmez. Örneğin, verilerinizi uluslararası standart adresle aynı veri öğesini 35 karakterle sınırlayan başka bir veritabanına yüklemeniz gerektiğinde büyük boyutlu veri değerleri istemezsiniz.