Neden bayrakları / kodları bir veritabanında tamsayılar yerine dizge olarak saklıyorsunuz?

Drupal 7, Wordpress (bazıları oldukça eski bir sürüm) ve Python tabanlı bazı özel uygulamalar da dahil olmak üzere bazı ünlü CMS'lerin SQL dökümlerine göz atıyordum.

Bu dökümlerin tümü, tamsayıları yerine dize bayraklarıyla veri içeriyordu. Örneğin, bir yayının durumu olarak temsil edildi published, closedya inheritziyade 1, 2ya 3.

Veritabanlarının tasarımı konusunda oldukça sınırlı bir deneyime sahibim ve hiçbir zaman basit SQL'leri geçmedim, ancak her zaman bunun gibi veriler için sayısal / tam sayı bayraklarını kullanmam gerektiğini öğrendim. tinyintBir veritabanında örneğin daha az yer kapladığı açıktır varchar(9).

Peki neyi özlüyorum? Bu bir veri depolama kaybı ve veri fazlalığı değil mi? Bu sütunlar dizgiler yerine tamsayılar kullanırsa, tarama, arama ve dizin oluşturma işlemleri biraz daha hızlı olmaz mıydı?

Evet, sayılar yerine dizeleri saklamak daha fazla alan kullanabilir. Yüksek profilli pltformların zaten bunu yapmasının nedeni, bu çözümün faydalarının maliyetten daha büyük olduğunu düşünmeleridir.

Faydaları nelerdir? Bir veritabanı dökümünü kolayca okuyabilir ve enum tablolarını ezberlemeden ne anlama geldiğini anlayabilirsiniz ve yarı-resmi GUI'ler bile aldıkları rekoru dönüştürmek yerine tematik değerleri kullanabilirler. (Bu, temel disk alanı / işlem süresi değişiminin biçimidir.)

Peki ya maliyet? Veri depolama kapasitesi, diskler çok büyük ve çok ucuz bir hale geldiğinden, uzun süredir CMS'deki darboğaz olmamıştır. Öte yandan, programcı süresi genellikle daha pahalı hale gelir - bu nedenle disk alanı için geliştirme çabası alan herhangi bir şey, iş perspektifinden de iyi bir şeydir.

Evet, küçücük bir şeyden daha fazla yer kaplayacak yesveya truealacak. Bu şaşırtıcı olmamalıdır. Ayrıca indeksleme yapar ve böylece veritabanı için daha az verimli bir şekilde birleşir. Ayrıca, doğru değerin ( yesvs y) ne olması gerektiği konusunda olası bir karışıklığa karşı da ceza vardır .

Ancak, veritabanında (özellikle MySQL) etkin olan dizelerde saklanmaya benzeyen pek çok yaklaşım vardır.

İlk olarak, MySQL, bu şekilde ayarlandığında bir Boole veya sınırlı bir dizi dizeye çok benzeyen bir enumtüre ( belgelere ) sahiptir. Ayrıca sadece geçerli değerleri girilen zorlar. Bu saklamak daha çoğu zaman çok daha yararlıdır 1, 2veya 3bir değer olarak anlam bilgileri ile taşınır. Enum, tür eklemek veya kaldırmak için bir şema değişikliğinin gerekli olduğu cezasını verir.

Bu bizi bir çocuk masasına ve yabancı anahtarlara (tüm veritabanlarına uygulanabilir) getirir. Evet, bir anahtar (için arka gibi bazı değerinin saklanması edilir 1, 2ya da 3) ve değeri published, closedve inheritbaşka bir masaya saklanır. Bir görünüm ( dokümanlar ) kullanarak , tablonun anahtar yerine dize içerdiğini görünmesini sağlamak mümkündür. Bunun, alt tabloya giriş eklemek veya kaldırmak için şema değişikliği gerektirmemesi avantajı vardır.

Tam olarak hangi şeylerin saklandığı, hangi yöntemin kullanılacağına karar vermek için şemanın asıl DDL'sine bakmak ve hangi işlemlerin seçildiğini görmek için bir ipucu gerektirir.