128/256/4096 bayt uzaklığa yuvarlanmış VARCHAR boyutlarını kullanmak için herhangi bir neden var mı?

Veritabanı şemalarında, genellikle VARCHAR boyutlarının 128/256 veya 4096 bayt uzaklığına yuvarlandığını fark ediyorum. Daha önce de yaptım ve arkasındaki fikir muhtemelen verimli bir şeydi.

Ancak, günümüzde hala geçerli bir neden var mı? Bu günlerde VARCHAR boyutları olarak genellikle '50', '100' veya '200' kullanıyorum, çünkü bunlar daha doğal ve tipik olarak kullanıcıya doğrulama denetimlerinde de gösteriliyor.

Aklıma gelen tek rasyonel açıklama şöyle olur: DBMS bir sütunun değerlerini sırayla depolarsa ve boyutlar 2 gücüne yuvarlanmazsa, bazı öğelerin sabit iki sayfaya "bölünmesi" gerekebilir bazı durumlarda sabit sürücüden biri yerine iki okumaya neden olabilecek sürücü (örneğin, sayfa n'deki ilk 10 bayt ve sayfa n + 1'deki sonraki 40 bayt).

@Jan Hudec'in, birçok programcının "128" veya "256" yı "güzel yuvarlak sayılar" olarak düşündüğü, 137, 19 veya 100 gibi tek sayılardan daha doğal bir seçenek haline getirdiği düşünülüyor.

Genel olarak bu sütun uzunlukları için bir neden yoktur. Bir varchar (100) sütununda varchar (128) sütununa göre performans artışı olmayacaktır.

Ancak, kısıtlamalar ve satıcıya özgü diğer uyarılar hakkında daha fazla açıklama için kullandığınız veritabanı sistemini iki kez kontrol ederim.

Örneğin, SQL Server için veritabanı sistemi kısıtlamasına iyi bir örnek:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

Satırın toplam uzunluğu, ayrı sütun uzunluklarından daha önemlidir.

Ben bir DBMS veya derleyici olup olmadığını hatırlamıyorum, ama (uzun zaman önce) dizi ve sütun uzunlukları için 2 güçlerini kullanmayı öğrenme hatırlıyorum. Uygulamanın bit kaydırmayı kullanabilmesi nedeniyle 'daha hızlı' olduğuna dair bir gerekçe vardı. Artık doğru olup olmadığı açık bir sorudur. Hala geçerli olup olmadığı hakkında bir fikri olan var mı?

BTW Sütun genişliklerini tekdüze sayı b / c'ye taşıdım. Kullanıcılara karakter sınırının 256 karakter olduğunu söylemek garip.

Ve bazı çok eski veritabanları sizi 256 karakter genişliğinde sütunla sınırlandırdı.

Muhtemelen gerçekten önemli değil, çünkü sadece tüm satırınızın boyutu 2'lik bir güç olsaydı, biraz depolama verimliliği görüyorsunuz. 2'lik güçlere bağlı kalmanız satır boyutunuzun daha muhtemel olmasını sağlayabilir. (çoğu yerel veri türü [veritabanına bağlı olarak] 2-boyutlu güç olma eğilimi olduğundan) iki güç için işe yarayacağını, ancak bunu zor ve hızlı bir kural yapmazdım.

Büyük (4K veya daha büyük) sütunlarla çalışıyorsanız daha mantıklı olabilir, çünkü bunlar ayrı olarak saklanabilir ve bunları bir depolama bloğuna sığacak şekilde boyutlandırabilir (veritabanınız disk üzerinde depolama için ne kullanırsa kullanın) bir şey.

Tüm DBMS sistemlerine aşina olmasam da, Oracle'daki en küçük "fiziksel" depolama birimi, varsayılan olarak 2 KB boyutunda olan bir "blok" tır. Sütunlarınızı iki güçle boyutlandırma uygulaması, satırlarınızı depolama bloklarına uygun şekilde boyutlandırma konusunda daha büyük bir uygulamanın bir parçasıdır. Sütunlarınızı bir satırın blok boyutundan bir bayttan fazla olmasını gerektirecek şekilde boyutlandırma, iki bloğun ayrılmasını gerektirir ve satırınız da iki bloğa yayılır, bu da her satıra bir bloğa sığabileceğinden daha fazla zaman harcayarak okuma, ekleme ve tarama yapar (ve her blokta yalnızca bir satır var). En azından bunun tarihi nedeni budur. Günümüzde çoğu insan bu uygulamayı alt optimizasyon olarak görmektedir.