Neden DB'de bir enum depolarsınız?

Ben gibi bir dizi soru gördüğüm bu DB Çeteleler saklamak için tavsiyeler soran. Ama bunu neden yaptın merak ediyorum . Diyelim ki Personbir genderalan ve bir Genderenum ile bir varlık var . Daha sonra, kişi masamın sütun cinsiyeti var.

Doğruluğu uygulamanın bariz nedeninin yanı sıra, uygulamamda genderzaten sahip olduğum şeyleri haritalandırmak için neden fazladan bir tablo oluşturduğumu da anlamıyorum . Ve ben de bu kopyalamayı sevmiyorum.

Şimdi daha az anlayışlı, beklenti dolu bir örnek daha alalım. Burada bir numara var ve bir hata için öncelikler kümesi.

Veritabanında hangi değeri saklıyorsunuz?

Yani, depolamak olabilir 'C', 'H', 'M've 'L'veritabanındaki. Veya 'HIGH'benzeri. Bu stringly yazılan veri sorunu var . Orada geçerli bir değerler bilinen kümesi vardır ve eğer değildir veritabanında bu kümeyi depolamak, onunla çalışmak zor olabilir.

Neden verileri kodda saklıyorsunuz?

Kodda List<String> priorities = {'CRITICAL', 'HIGH', 'MEDIUM', 'LOW'};bu etkiyi veya başka bir şey var . Bu, bu verilerin çeşitli biçimlerini uygun formata sahip olduğunuz anlamına gelir (tüm büyük harfleri veritabanına ekliyorsunuz, ancak bunu görüntülüyorsunuz Critical). Kodunuz artık yerelleştirmek için de zor. Fikrin veritabanı temsilini kodda depolanan bir dizeye bağladınız.

Bu listeye erişmek için ihtiyacınız olan her yerde, kod çoğaltmaya ya da bir sürü sabit olan bir sınıfa ihtiyacınız olacaktır. Hiçbiri iyi seçenek değil. Ayrıca , bu verileri kullanabilecek başka uygulamalar da olduğunu unutmamak gerekir (diğer dillerde yazılmış olabilir - Java web uygulamasında kullanılan Crystal Reports raporlama sistemi ve içine Perl toplu iş besleme verileri vardır). Raporlama motorunun geçerli veri listesini bilmesi gerekir ( 'LOW'öncelikli olarak işaretlenmiş hiçbir şey olmazsa ne olur ve bunun rapor için geçerli bir öncelik olduğunu bilmeniz gerekir?) Ve toplu işin ne geçerli olduğu hakkında bilgi sahibi olur. değerler

Varsayalım, sen belki "Biz tek dil dükkanıysanız - her şey Java ile yazılmış" demek ve bu bilgileri içeren tek .jar var - ama şimdi sizin demektir uygulamalar sıkıca birbirlerine bağlanır ve bu .jar içeren veri. Her değişiklik olduğunda raporlama bölümünü ve toplu güncelleme bölümünü web uygulamasıyla birlikte serbest bırakmanız gerekir - ve bu sürümün tüm parçalar için sorunsuz bir şekilde uygulanacağını umarsınız .

Patronunuz başka bir öncelik istediğinde ne olur?

Patronun bugün geldi. Yeni bir öncelik var - CEO. Şimdi tüm kodu gidip değiştirmek ve yeniden derlemek ve yeniden konuşlandırmak zorundasınız .

'Tabloda enum' yaklaşımıyla, enum listesini yeni bir önceliğe sahip olacak şekilde güncellersiniz. Listeyi alan tüm kod veritabanından onu çeker.

Veriler nadiren tek başına durur

Önceliklerle, veriler iş akışları hakkında bilgi içerebilecek veya bu önceliği ya da neyi ayarlayabilecek başka tablolara girer .

Bir miktar soruda belirtildiği gibi cinsiyete geri dönme: Cinsiyet, kullanılan zamirlerle bir bağlantıya sahiptir: he/his/himve she/hers/her... ve bunu kodun kendisine zorla kodlamaktan kaçınmak istersiniz. Ve sonra patronunuz geliyor ve eklemenizin 'OTHER'cinsiyete sahip olduğunu eklemeniz gerekiyor (basit tutmak için) ve bu cinsle ilişki kurmanız gerekiyor they/their/them... ve patronunuz Facebook'un sahip olduğunu ve ... evet, evet.

Kendinizi bir enum tablosu yerine dizge biçiminde yazılan bir veri bitiyle sınırlandırarak, şimdi verilerle diğer bitler arasındaki ilişkiyi korumak için bu dizgiyi başka bir grup tabloda çoğaltmanız gerekir.

Peki ya diğer veri depoları?

Bunu nerede sakladığınız önemli değil, aynı ilke var.

• priorities.propÖncelikler listesine sahip bir dosyanız olabilir . Bu listeyi bir özellik dosyasından okudunuz.

• Bir girişi olan bir belge deposu veritabanına ( CouchDB gibi ) sahip olabilirsiniz enums(ve ardından JavaScript'te bir doğrulama işlevi yazabilirsiniz ):

  {
     "_id": "c18b0756c3c08d8fceb5bcddd60006f4",
     "_rev": "1-c89f76e36b740e9b899a4bffab44e1c2",
     "priorities": [ "critical", "high", "medium", "low" ],
     "severities": [ "blocker", "bad", "annoying", "cosmetic" ]
  }
  

• Biraz şema içeren bir XML dosyanız olabilir:

  <xs:element name="priority" type="priorityType"/>
  
  <xs:simpleType name="priorityType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="critical"/>
      <xs:enumeration value="high"/>
      <xs:enumeration value="medium"/>
      <xs:enumeration value="low"/>
    </xs:restriction>
  </xs:simpleType>
  

Temel fikir aynı. Veri deposunun kendisi, geçerli değerler listesinin saklanması ve uygulanması gereken yerdir. Buraya yerleştirerek, kod ve veriler hakkında düşünmek daha kolaydır. Her seferinde neye sahipseniz savunma olarak endişelenmenize gerek yok (büyük harf mi, küçük mü? Neden chriticalbu sütunda bir tür var ? Vb ...) çünkü veri deposundan ne aldığınızı biliyorsunuz Veri deposunun tam olarak ne göndermeni beklediğini - ve geçerli bir liste için veri deposunu sorgulayabilirsiniz.

Götürmek

Geçerli değerler kümesi kod değil veridir . Sen do için çaba gerekir KURU kod - ama çoğaltılması sorunu da kopyasını olmasıdır verileri ziyade veri olarak yerini saygı ve bir veritabanında depolayarak daha kodda.

Daha kolay veri deposuna karşı birden fazla uygulama yazma yapar ve sıkıca verinin kendisine bağlandığı her şeyi dağıtmak gerekir örneklerini zorunluluğunu ortadan kaldırır - nedeniyle henüz verilere kodunuzu çiftleşmiş.

CEOÖncelik eklendiğinde uygulamanın tamamını tekrar test etmeniz gerekmediğinden test uygulamalarını kolaylaştırır - çünkü önceliğin gerçek değerini önemseyen bir kodunuz yoktur.

Kod ve verileri birbirinden bağımsız olarak aktarabilmek, bakım yaparken hataları bulmayı ve düzeltmeyi kolaylaştırır.

Bunlardan hangisinin sorguyu okurken hata üretmesi daha olasıdır?

select * 
from Person 
where Gender = 1

Veya

select * 
from Person join Gender on Person.Gender = Gender.GenderId
where Gender.Label = "Female" 

İnsanlar SQL'de enum tabloları yaparlar çünkü ikincisini daha okunaklı bulurlar - bu da SQL yazma ve sürdürmede daha az hataya yol açar.

Cinsiyet doğrudan bir dize haline gelebilir Person, ancak o zaman davayı denemek ve uygulamak zorunda kalacaksınız. Ayrıca, DB'nizin işleri optimize etmesinde ne kadar harika olduğuna bağlı olarak, dizeler ve tam sayılar arasındaki fark nedeniyle tablo için depolama isabetini ve sorgu süresini artırabilirsiniz.

İnsanların henüz bundan bahsetmediğine inanamıyorum.

Yabancı anahtarlar

Enum'u veritabanınızda tutarak ve bir enum değeri içeren tabloya bir yabancı anahtar ekleyerek , hiçbir kodun o sütun için yanlış değerler girmemesini sağlayabilirsiniz . Bu, veri bütünlüğünüze yardımcı olur ve IMO'nun enums için tablolara sahip olması gereken en açık nedendir.

Seninle aynı fikirde olan kamptayım. Cinsiyet kodunu kodunuzda tutarsanız ve veritabanınızdaki bir tblGender kodunu kullanırsanız, bakım sırasında sorun yaşayabilirsiniz. Bu iki varlığın aynı değerlere sahip olması gerektiğini ve böylece birinde yapmanız gereken değişiklikleri diğerinde yapmanız gerektiğini belgelemeniz gerekecektir.

Daha sonra enum değerlerini aşağıdaki gibi saklı yordamlarınıza geçirmeniz gerekir:

create stored procedure InsertPerson @name varchar, @gender int
    insert into tblPeople (name, gender)
    values (@name, @gender)

Ancak, bu değerleri bir veritabanı tablosunda tutarsanız, bunu nasıl yapacağınızı düşünün:

create stored procedure InsertPerson @name varchar, @genderName varchar
    insert into tblPeople (name, gender)
    select @name, fkGender
    from tblGender
    where genderName = @genderName --I hope these are the same

Tabii ilişkisel veri tabanları bir araya getirilerek oluşturuldu, ancak hangi sorgunun okunması daha kolay?

İşte başka bir örnek sorgu:

create stored procedure SpGetGenderCounts
    select count(*) as count, gender
    from tblPeople
    group by gender

Bunu bununla karşılaştırın:

create stored procedure SpGetGenderCounts
    select count(*) as count, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender
    group by genderName --assuming no two genders have the same name

İşte başka bir örnek sorgu:

create stored procedure GetAllPeople
    select name, gender
    from tblPeople

Bu örnekte, sonuçlarınızdaki cinsiyet hücresini int'den bir enuma dönüştürmeniz gerekeceğini unutmayın. Ancak bu dönüşümler kolaydır. Bunu bununla karşılaştırın:

create stored procedure GetAllPeople
    select name, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender

Enum tanımlarını veritabanından uzak tutma fikrinizle devam ederken, bu sorguların tümü daha küçük ve daha bakımlıdır.

Veri analizinde kullanılabileceği için bir Cinsiyet tablosu oluşturacağım. Bir rapor oluşturmak için veritabanındaki tüm Erkek veya Kadın Kişileri arayabilirim. Verilerinizi ne kadar çok izleyebiliyorsanız, trend bilgilerinizi o kadar kolay keşfedersiniz. Açıkçası, bu çok basit bir numaralandırmadır, ancak karmaşık numaralandırmalar için (dünyadaki ülkeler veya ülkeler gibi), özel raporlar oluşturmayı kolaylaştırır.

Öncelikle, veritabanının yalnızca bir uygulama tarafından kullanılıp kullanılmayacağına ya da birden fazla uygulamanın onu kullanma potansiyeli olup olmadığına karar vermeniz gerekir. Bazı durumlarda veritabanı, bir uygulama için bir dosya biçiminden başka bir şey değildir (SQLite veritabanları bu konuda sıklıkla kullanılabilir). Bu durumda, enum tanımını tablo olarak çoğaltma biti genellikle iyi olabilir ve daha anlamlı olabilir.

Ancak, veritabanına erişen birden fazla uygulamanın bulunma olasılığını göz önüne almak istediğinizde, enum için bir tablo çok mantıklıdır (diğer cevaplar neden daha ayrıntılı olarak açıklanmaktadır). Dikkate alınacak diğer şey siz veya başka bir geliştirici ham veritabanı verilerine bakmak isteyeceksiniz. Eğer öyleyse, bu başka bir uygulama kullanımı olarak kabul edilebilir (yalnızca laboratuvar göstergesinin ham SQL olduğu bir alan).

Kodda tanımlanmış numaralandırmayı (temizleyici kodu ve derleme zamanı denetimi için) ve veritabanındaki bir tablo varsa, ikisinin senkronize olduğunu doğrulamak için birim testleri eklemenizi öneririm.

İş mantığını koda sürmek için kullanılan bir kod numaralandırmanız varsa, yukarıda / aşağıda açıklanan birçok nedenden dolayı DB'deki verileri temsil etmek için bir tablo oluşturmanız gerekir. DB değerlerinin kod değerleriyle eşit kalmasını sağlamak için birkaç ipucu:

1. Tablodaki kimlik alanını Kimlik sütunu yapmayın. Kimlik ve Açıklama'yı alan olarak ekleyin.

2. Tabloda, geliştiricilerin değerlerin yarı statik / kod numaralandırmasına bağlı olduğunu bilmelerine yardımcı olan farklı bir şey yapın. Diğer tüm arama tablolarında (genellikle değerlerin kullanıcılar tarafından eklenebileceği yerlerde) tipik olarak bir LastChangedDateTime ve LastChangedBy'ye sahibim, ancak bunları enum ile ilgili tablolarda bulundurmamak, yalnızca geliştiriciler tarafından değiştirilebilir olduklarını hatırlamama yardımcı oluyor. Bunu belgeleyin.

3. Numaralandırmadaki her değerin karşılık gelen tabloda olduğunu ve yalnızca bu değerlerin karşılık gelen tabloda olduğunu görmek için doğrulama kodu oluşturun. Yapma sonrası çalıştırılan otomatikleştirilmiş "sağlık testleri" uygulamanız varsa, orada. Değilse, uygulama IDE'de çalışırken kodun uygulama başlangıcında otomatik olarak çalışmasını sağlayın.

4. Üretim oluşturma, aynı şeyi yapan, ancak DB içinden SQL komut dosyaları sunar. Doğru yaratılırlarsa, çevre göçlerine de yardımcı olurlar.

Ayrıca verilere kimin eriştiğine de bağlıdır. Sadece iyi bir uygulama varsa. Bir veri ambarı veya raporlama sistemi eklerseniz. Bu kodun ne anlama geldiğini, kodun insan tarafından okunabilir versiyonunun ne olduğunu bilmeleri gerekir.

Genellikle, tür tablosu koddaki bir enum olarak çoğaltılmaz. Tür tablosunu önbelleğe alınmış bir listeye yükleyebilirsiniz.

Class GenderList

   Public Shared Property UnfilteredList
   Public Shared Property Male = GetItem("M")
   Public Shared Property Female = GetItem("F")

End Class

Genellikle, yazın gelir ve gider. Yeni türün eklendiği tarih için tarih gerekir. Belirli bir türün ne zaman kaldırıldığını bilin. Sadece gerektiğinde görüntüleyin. Bir müşteri cinsiyet olarak "transeksüel" ister ancak diğer müşteriler istemezse ne olur? Bu bilgilerin tümü en iyi şekilde veritabanında depolanır.