SQL Server'da varchar boyutlandırma ile ilgili mevcut en iyi uygulamalar nelerdir?

Depolama ve performans açısından hem varchar sütunlarının ne kadar büyük olması gerektiğine karar vermenin en iyi yolunu anlamaya çalışıyorum.

Performans
Araştırmamdan, öyle görünüyor kibu varchar (max) yalnızca gerçekten ihtiyacınız varsa kullanılmalıdır; yani, sütun 8000'den fazla karakter barındırması gerekiyorsa, bir nedeni dizinleme eksikliği (genel olarak varchar alanları üzerinde dizinleme biraz şüpheli olsa da. DB ilkeleri için oldukça yeni olsa da, belki de bu asılsız ) ve sıkıştırma (daha fazla depolama sorunu). Aslında, genel olarak insanlar varchar (n) yaparken sadece ihtiyacınız olanı kullanmanızı tavsiye ediyor gibi görünüyor .... büyük boy kötü, çünkü sorgular mümkün olan en büyük boyutu hesaba katmalıdır. Ancak motorun, verilerin ortalama gerçek boyutunun bir tahmini olarak belirtilen boyutun yarısını kullanacağı da belirtildi. Bu, verilerin ortalama boyutun ne olduğunu belirlemesi, ikiye katlaması ve bunu n olarak kullanması gerektiği anlamına gelir. Yine de çok düşük ancak sıfır olmayan değişkenliğe sahip veriler için, Bu, maksimum boyut üzerinde 2 kat fazla büyüklük anlamına gelir, ki bu çok gibi görünüyor, ama belki değil mi? Anlayışlar takdir edilecektir.

Depolama
Sıralı veya sıra dışı depolamanın nasıl çalıştığını okuduktan ve gerçek depolamanın gerçek verilerle sınırlı olduğunu akılda tuttuktan sonra, aslında n seçiminin depolama üzerinde çok az ya da hiç etkisi olmadığı anlaşılıyor. her şeyi tutacak kadar büyük olduğundan emin olun). Varchar (max) kullanmanın bile depolama üzerinde herhangi bir etkisi olmamalıdır. Bunun yerine, her veri satırının gerçek boyutunu mümkünse ~ 8000 bayt ile sınırlamak bir hedef olabilir. Bu şeyler hakkında doğru bir okuma mı?

Bağlam
Müşteri verilerimizden bazıları biraz dalgalanıyor, bu nedenle bu sütunlar için sütunları genellikle olması gerekenden biraz daha geniş yapıyoruz, örneğin% 15-20 daha büyük. Başka özel hususlar olup olmadığını merak ediyordum; Örneğin, birlikte çalıştığım biri bana 2 ^ n - 1 boyut kullanmamı söyledi (bununla ilgili hiçbir kanıt bulamadım ....)

İlk tablo oluşturma hakkında konuşuyorum. Bir müşteri bize yeni bir tablo göndermeye başlayacaklarını ve verileri tutmak için elimizde bir tablo yapacağımız örnek verileri (veya sadece ilk üretim veri setini) göndereceklerini söyleyecektir. Gelecekteki ithalatı ve numunede ne olduğunu ele almak için masaya son vermek istiyoruz. Ancak, bazı satırların uzaması gerekir, bu yüzden onları doldururuz.

Soru ne kadar ve teknik yönergeler var mı?

Belirli veri türünden bağımsız olarak, uygulamanın depolanmasını istediği her şeyi depolayabilmeniz gerekir. Gerçekten kaydedileceklerin maksimum boyutundan daha küçük bir şey belirtemezsiniz.

Ayrıca, çeşitli nedenlerle saklanacak maksimum gerçek boyuttan daha büyük bir sütun uzunluğu belirtmenize de gerek yoktur: sorgu belleği ayırma, potansiyel olarak maksimum satır boyutunu doldurma ve sütun eklemek için yer bırakma gelecek vb.

Doğru, değişken uzunluklu dize ve ikili sütunlar, sabit uzunluklu veri türlerinin (dize / ikili / sayısal / tarih / vb.) Yaptığı depolama etkisine sahip değildir (ancak, bu sonuçlardan bazıları veri sıkıştırma veya SPARSEsütun tanımının kullanımı yoluyla geçersiz kılınabilir seçenek). Ancak, belirttiğiniz gibi, doğrudan depolama etkisi olmasa bile, sorgular için gerekli belleğin fazla tahmin edilmesinin performans etkisi hala vardır.

Duyarlı olmak. İhtiyacın neyse sadece onu kullan. Sütun uzunluğunun yakın gelecekte artması olasılığı yüksekse dikkate alınabilir, ancak bir sütunun boyutunu büyütmenin boyutu küçültmekten daha kolay olduğunu unutmayın. Evet, bazı çalışmalar yapılacak, ancak bu iş sadece "potansiyel" olduğu için, aşırı boyutlandırmanın performans sonuçları "gerçek" iken, sütunları tanımlamak en iyisi olabilir -spor gelecekte ihtiyacınız olabileceğini düşünüyorum. Hakkında konuşulan pek çok değişiklik asla gerçekleşmez ve çoğu zaman gerekli değişiklikler öngörülemez. Bildiklerinle git.

Bunun yerine, her veri satırının gerçek boyutunu mümkünse ~ 8000 bayt ile sınırlamak bir hedef olabilir.

Burada ne elde ettiğinden tam olarak emin değilim. SQL Server, sizi fiziksel olarak 8000 baytın üzerinde sınırlar. LOB türünün kullanılması üzerinde - VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, ve artık TEXT, NTEXTve IMAGEtürleri - bu ilk sayfa boyutu sınırlama ötesinde olanak, ancak bunun nedeni ile türüne bağlı olarak bir işaretçi (16 ya da daha fazla bayt, yerleştirme ve bağlı olarak sadece MAXtürleri kullanılırken satır dışına kaydedilen değerin boyutu ). Veri sayfasının gerçek fiziksel sınırı değişmedi.

Amacınız, eksik değer anlamını yitirecek veya aşağı yönde sorunlara neden olacak şekilde uygulamanın / işletmenin depolamak için ihtiyaç duyduğu şeyleri kırmadan veya kesmeden depolamak için en az miktarda fiziksel alan kullanmak olmalıdır. 12.000 karakterlik bir şey saklamanız gerekiyorsa kullanın, VARCHAR(MAX)çünkü gerekli olan budur. Bir telefon numarası veya posta / posta kodu saklıyorsanız, kullanmak akıllıca olmaz ve kullanımı VARCHAR(100)sorumsuz olur VARCHAR(MAX).

bazı müşteri verilerimiz biraz dalgalanıyor, bu nedenle bu sütunlar için genellikle% 15-20 daha büyük olması gereken sütunları biraz daha geniş hale getiriyoruz. Başka özel hususlar olup olmadığını merak ediyordum;

Tüm sistemlerin dalgalanan en azından bazı verileri yok mu? Bir kişinin adını saklayan herhangi bir sistem yeterlidir, değil mi? İsimlerin uzunluğunda oldukça büyük bir varyans var. Ve sonra Prens gibi birinin gidip adını bir sembole çevirmesini sağladın ve şimdi uzunluk olmayan tamamen farklı bir problemin var. İşler böyle.

Ancak, bir an için şeytanın avukatını oynamak için: "ihtiyaç duyulandan% 15-20 daha büyük" değer gerçek gereken değer nasıl olamaz ? Diyelim ki yeni bir sütun eklemekle ilgili bir tartışma var ve birisi 50 karakter öneriyor, sonra birileri "% 20 daha fazla 60 yani 60 tane yapalım çünkü 60 tane olabilir." Bir müşterinin 60 olabileceği doğruysa, o zaman 60 ve gerekli olan gerçek değerdi ve 50 her zaman yanlıştı.

Tabii ki, verilerin kaynağı ile ilgili bazı göstergeler varsa yardımcı olacaktır çünkü:

1. "URL" 1024 yaparsanız ve birisinin 1060'a ihtiyacı varsa, o zaman 1060 olması gerekir (benzer şekilde, URL yaparsanız VARCHARve artık alan adlarında izin verilen Unicode karakterlerini karıştırdığından şikayet ederseniz, olması gerekir NVARCHAR), fakat
2. Birisi daha sonra, 500 karakter sınırı yorum alanına 1000 karakterler eklemek istiyorsa hala sadece gerekli 500. İnsanlar (yorumlarda az ayrıntılı ;-) benim için büyük bir sorun olabilir olmak, ancak ProductSKUdaha iyi tüm sığdırmak için yeterince büyük olması müşterinin SKU'larının.

İlk tablo oluşturma hakkında konuşuyorum. Bir müşteri bize yeni bir tablo göndermeye başlayacaklarını ve verileri tutmak için elimizde bir tablo yapacağımız örnek verileri (veya sadece ilk üretim veri kümesini) göndereceklerini söyleyecektir. Gelecekteki ithalatı ve numunede ne olduğunu ele almak için masaya son vermek istiyoruz. Ancak, bazı satırların uzaması gerekir, bu yüzden onları doldururuz. Soru ne kadar ve teknik yönergeler var mı?

Burada çok fazla varsayım yapıyorsunuz . Tabii bazı alanlar daha büyük olabilir . Ama sonra tekrar, olmayabilirler. Veya bazıları küçülebilir. Bazıları Unicode olmamaktan Unicode olmaya dönüşebilir (dünyanın küçüldüğünü ve soyadlarının sadece temel ASCII / US İngilizce karakterlere sahip olacağını varsayamazlar). Veya alan göndermeyi bırakabilirler. Veya gelecekte bir veya daha fazla alan ekleyebilirler. Bu ve diğer şeylerin herhangi bir kombinasyonu. Öyleyse neden sadece VARCHARsütunlara odaklanalım ? Ya şu anda bir INTdeğer gönderiyorlarsa ve bir ya da iki yıl içinde maksimum değere ulaşıp a göndermeye başlıyorlarsa BIGINT? 0 - 5 arasında bir "durum" alanı varsa ne olur?INThangi "yastıklı" olduğu için büyüme sağlar, ama muhtemelen olması gerekir TINYINT?

Güvenle tahmin edebileceğiniz tek şey, müşterilerinizin verilerinin nasıl değişeceğini tahmin etmeye çalışmanın, doğru olduğundan daha sık yanlış olacağıdır. Ve doğru olmak şans / tesadüf meselesidir (şans değilse, sadece piyangoyu oynayın;).

Yani kılavuz:

1. Cevaplanamayan bir soruyu cevaplamaya çalışırken zaman ve enerji harcamayın.
2. Bunun yerine, müşterinizin gerçek verileri hakkında mümkün olduğunca fazla bilgi almaya odaklanın ve bununla devam edin (yani veri odaklı karar verme ;-).

Zaten örnek verileriniz var, harika. Ancak, lütfen müşterinizin iletişim bilgilerine de sahip olduğunuzu unutmayın: telefon ve / veya e-posta. Onlarla iletişime geç! Onlardan veri özelliklerini isteyin (tıpkı sisteminizde olduğu gibi, şu anda sistemlerinde bulunan verilerin maksimum uzunluğu 35 olabilir, ancak sistemleri olarak tanımlanmıştır VARCHAR(50)ve sistemleri bu uzunluğa kadar kabul edecektir, bu durumda kullanmalısınız 50). Ayrıca, onlara yakın dönem değiştirme planları olup olmadığını ve bu veri türlerini (tip ve / veya boyut) sorun.