Varchar (8000) ayarının sonuçları nelerdir?

22

Varchar, alanın boyutuna orantılı disk alanı kapladığından, varchar'ı her zaman maksimum olarak tanımlamamamız için herhangi bir neden var varchar(8000)mı , örneğin SQL Server'da?

Tablo oluştururken, yapan birini görürsem varchar(100)onlara yanlış olduğunuzu söylemeliyim, yapmalısınız varchar(8000)?

sql-server varchar

— Aleksandr Levchuk
kaynak

Burada, create table içindeki kullanım ile saklı yordamların parametre bildirimlerindeki kullanım arasında ayrım yapmamız gerektiğini düşünüyorum. İkinci yorum için soruma

— bernd_k

18

Uzunluk, veriler üzerindeki bir kısıtlamadır (CHECK, FK, NULL gibi)
Satır 8060 baytı aştığında performans
Benzersiz kısıtlama veya dizin bulunamıyor (anahtar sütun genişliği <900 olmalıdır)
Varsayılan değer SET ANSI PADDING ON = saklanacak çok sayıda takip alanı için potansiyel
SQL Server sıralama işlemleri için ortalama uzunluk 4000 olduğunu varsayar, buna dayalı bellek ayırır.

Özet: yapmayın.

— GBN
kaynak

Satır 8060 baytı aştığında performans . Bu gerçek kullanılan baytları ifade eder ve izin verilen maksimum baytları değil.

— bernd_k

@bernd_k: 8060 = tek bir 8192 sayfaya sığacak olan bir satır için en büyük miktarda veri. Satır ek yükünü dahil et Kalan (132 bayt) = sayfa ek yükü

— gbn

Bu, büyük boyutta gerçekten kullanıldığında, kullanımına izin verildiğine göre gerçek anlamda değil performansın azaldığı anlamına gelir.

— bernd_k

@bernd_k: herhangi bir performans düşüşüne 1. tür vb. bellek ayırma neden olur. 2. Satır taşması (> 8060 bayt). Her değişkende (8000) 10 karakter bulunması, bu koşullar yerine getirilinceye kadar ilgisizdir (SQL, indeks anahtarları için daha sonra olası hatalar konusunda uyarır)

— gbn

Sıralama, ortalama 50 karakter varsayarsak, 100 bayt uzunluğundaki alanlarla dolu varchar (100) sütunu olan bir tabloyu sıralamak mı?

— bernd_k

7

SQL Server'a atıfta bulunduğunu varsayarsak, birini düşünebilirim.

Bir tabloda bir satırın boyutu (8K) var ve SQL teorik olarak bu limiti aşabilecek varchar alanları tanımlamanıza izin veriyor. Böylece kullanıcı, bununla ilgili alanda çok fazla veri koyarsa hata alabilir.

SQL 2K8 ile başlayarak bu sınırı aşabilirsiniz, ancak performans etkileri var .

Ayrıca, verinin görünmesini beklediğiniz boyutla sınırlandırmanın tüm makulluk kontrolü vardır. Sınırlandırılmamış bir uzunluk alanı istiyorsanız, neden metin veya ntext ile gitmiyorsunuz?

— JohnFx
kaynak

yani metin ve ntext veri tipleri performansı etkilemeyecek şekilde saklanır?

— Chad,

Bu türler, bir tablodaki 8K satır boyutu sınırına kadar katkıda bulunmaz; çünkü gerçek veriler, sütunların geri kalanıyla aynı çizgide değil, kapakların altında ayrı bir tabloda saklanır. Hala bir performans etkisi var, ancak farklı nedenlerden dolayı. Bu alanlardaki özellik desteğinde varchar ve nvarchar ile kıyaslandığında bazı sınırlamalar da var

— JohnFx

text ve ntext, varchar (max) lehine kaldırılmıştır.

— Phil Helmer

3

Elbette, bu alanda hangi bilgilerin depolandığına bağlı?

Bazı şeyler bir takım sebeplerden dolayı maksimum uzunluğa sahip olacak ve eğer maksimum uzunluk olması gerekiyorsa bu alanınızın uzunluğu olmalıdır.

Teorik olarak maksimum uzunluk yoksa, neden varchar'ın kullanılacağını sorgularım.

— Toby
kaynak

3

Oracle Veritabanları bağlamında, Veritabanı sütunları için her zaman en küçük alan boyutunu kullanmanın tek bir sorun olduğunu öğrendim.

Verileri içe aktarma yoluyla tek bayt harmanlama içeren bir veritabanından çoklu bayt harmanlama olana (Oracle XE gibi) aktarırken, bayt cinsinden uzunluk, verileri içe aktarma işlemi tarafından oluşturulan tablolara aktarabilir ve içe aktarabilir. Elbette Oracle, varchar2 uzunluğunu char veya bayt olarak tanımlayabiliyor.

Buradaki noktam, alanı her zaman mümkün olduğu kadar küçük bir şekilde tanımlamanın her zaman akıllıca olmadığıdır. Daha sonra tarlaları arttırmak için birçok değişik tablo gördüm (değişen gereksinimlerden dolayı).

% 20 -% 100 kullanılmayan alana sahip olmak burada tartışılabilir bir seçenek.

— bernd_k
kaynak