Koddaki statik veritabanı verilerine başvurmanın en iyi yolu?

Birçok uygulama 'statik veri' içerir: uygulamanın kullanım ömrü boyunca gerçekten değişmeyen veriler. Örneğin, öngörülebilir gelecek için sabit bir liste olması muhtemel Satış Alanları listesine sahip olabilirsiniz.

Bu statik verileri bir veritabanı tablosunda bulmak nadir değildir (genellikle diğer tabloların yabancı anahtarlarında buna başvurmak istediğiniz için). Basit bir örnek tabloda, birincil anahtar olarak kullanılacak bir Id ve bir Açıklama olacaktır. Örneğin, SalesArea tablonuzda (en azından) bir SalesAreaId sütunu ve bir SalesAreaDescription sütunu olacaktır.

Şimdi, kodda, tablonun her satırına aynı şekilde davranmak istemeyebilirsiniz. Örneğin, bazı ekranlarda varsayılan bir Satış Alanı belirlemek, bazı alanlar için farklı rakamlar sağlamak veya kullanıcıların diğer alanlarda yapabileceklerini sınırlamak isteyebilirsiniz.

Koddaki bu statik verilere başvurmanın en iyi yolu nedir? Niye ya?

1. Kodunuzdaki açıklamaları sabit kodlayın. Bunu, ihtiyacınız olduğunda veritabanından SalesAreaId'ye bakmak için kullanın.
2. Kodunuzdaki kimlikleri kodlayın. Bunu ihtiyacınız olduğunda SalesAreaDescription'a bakmak için kullanın.
3. Her bir amaç için tabloya bir sütun ekleyin, örneğin bir "IsDefaultOnProductLaunchScreen" sütunu vb. (Bunlardan çok olabilir).
4. Başka bir şey.

Statik veri tabanı verileri ile çalışırken dikkate almam gereken başka özel hususlar var mı? Örneğin, bu tablolara özel bir ad vermek?

Uygulama başlatıldığında bunları bir önbelleğe (genellikle karma tablo olarak uygulanır) yüklerseniz ne olur? Bunu yaparsanız, veritabanını sorgulamanız bile gerekmez (peki, bir kereden fazla değil).

Ayrıca herhangi bir şeyi kodlamaktan kaçınmayı önerebilirim. Varsayılan göstergeler gerektiren ekranlar için varsayılan göstergeler (başlangıçta DB tablosunda ve ayrıca önbellek yapısında) ekleyin. Varsayılan olmayanlara göz atmak için, aranacak anahtarları bir yapılandırma veya özellikler dosyasında tutmaya çalışın.

DB veya sabit kodlamaya alternatif, başlangıçta okunan bir config dosyası kullanmaktır. Daha sonra bu verileri kodunuzdaki salt okunur bir yapıya kaydedebilirsiniz.

Bu verileri düzenlediğiniz nadir (ancak imkansız olmayan) durumda, uygulamayı yeniden başlatmanız gerekir. Bu mümkün değilse, verilere her erişildiğinde yapılandırma dosyasındaki değişiklikleri kontrol eden daha karmaşık bir yapılandırma yöneticisi yazabilirsiniz, bu yalnızca dosya üzerinde bir zaman damgası kontrol etmeniz ve ardından tüm verileri geçersiz kılmanız gerektiğinden oldukça etkilidir. eğer dosya güncellendiyse.

Veri DB'nizdeki mevcut verilerle ilişkiliyse, büyük olasılıkla veri tabanına eklemek için veri tabanına DB eklemek de etkilidir. Öyleyse, genellikle "bir kez bu kurşunu al" diyeceğim ve ilk değiştirene kadar koda koyacağım.

Genelde statik olacağını düşündüğümüz şeyin olmadığı ortaya çıkıyor ve bu olduğunda, bir değişimin gerçekleşmesi için bir kod yayımını beklemek zorunda kalmazsınız. Bir kez olur olmaz, veritabanına koyun ve daha fazla güncelleme yapmak için bir yönetici sayfası yazın.

Örnek almak gerekirse, DB'de zaten Satış Alanları varsa, orada bir açıklama ekleyin, veritabanı verilerini kodlanmış listelerle ilişkilendirmek için bir karma tablo oluşturmayın. Ancak, daha sonra Satış Alanları karma tablosunu oluşturmazsanız, ancak hazır olun, ilk defa bir kişi bir açıklama değiştirdiğinde veya yeni bir Satış Alanı eklediğinde, onu DB'ye taşıyın.

Neden sadece her şeyi zor kodlamıyorsun? Hep yaşadım asıl sorun ise başvuran uygulama kodunda DB'den statik değerler. Doğrudan açılan bir liste veya statik değerlerin dışında bir şey oluşturuyorsanız bir şey olabilir; ancak bazı uygulama mantıkları DB'nin değerlerine bağlıysa ne olur?

Basit bir uygulamada şu anda içerik parçaları için düzenleme durumlarının bir listesine sahibim: Taslak, Yayınlandı, Arşivlendi.

İçerik öğelerinin, hangi durumda olduklarına bağlı olarak farklı şekilde ele alınması gerekir. Bu durum verilerini DB'de saklarsam, sırasıyla 1, 2, 3 değerleriyle, bir şeyin Taslak olup olmadığını nasıl kontrol edebilirim? belirtmek, bildirmek?

if (content.State == 1)
ya
if (content.State == "Draft")?

Sadece değerleri kodladım!
Aynı şey bir önbellek / karma tablo kullanıyorsanız: Verilerinize bakmak için hala kodunuzda yazılı bir değeri kullanmanız gerekir.

Sabit kodlama yaklaşımının dezavantajları nelerdir?

FrustratedWithFormsDesigner'ın söylediğine benzer şekilde, bu genellikle bir önbellekle yapılır, çünkü statik verileri yalnızca bir kez yüklemeniz gerektiği anlamına gelir, ancak OAOO düzenini izler, yani verileri iki yerde tanımlamıyoruz (veritabanı ve senin kodun).

NHibernate ORM'nin bu işlevi 2. seviye bir önbellek ile sunduğunu biliyorum . Verileri belirli bir tablodan önbelleğe almasını söyleyebilir ve salt okunur olduğunu söyleyebilirsin. İlk defa gerektiğinde yüklenecek ve verilere birden çok oturumdan erişseniz bile, bundan sonra tekrar veritabanına gelmeyecek.

Bu, daha da kötüsü için erken optimizasyon.

Öncelikle herhangi bir modern DBMS, küçük tablolardan yıldırım hızındaki verileri alacaktır ve hepsinde, iyi ila üstün arasında değişen önbellek algoritmaları bulunur (DBMS için ne kadar fazla ödeme yaparsanız, önbellekleme o kadar iyi olur!). Demek asgari kaynakları tüketen bir şeyi optimize ediyorsun.

İkincisi, "satış alanı" gibi bir şeyin statik veri olduğunu hayal ediyorsanız, gerçek dünya iş uygulamalarında çok az deneyime sahip olursunuz. Bunlar Pazarlama Direktörünün veya CEO'nun her değişikliğinde değişiklik yapmakla yükümlüdür. Demek iki yıl boyunca acı dolu bir dünyaya gidiyorsun.

Buraya gitmenin sadece iki yolu var: -

Bir veritabanında saklayın ve verilere "normal" sql ile erişin.

“Politik bir politika değişikliği” olduğunda kolayca düzenlenebilen süslü bir XML yapılandırma dosyasında (muhtemelen REST veya SOAP yoluyla erişilebilir) saklayın.

Bu, verilerle ne yaptığınıza bağlıdır. Eğer bir şeyin listesi ise, genellikle onu bir diziye çekerim. Listenin başka bir sürümde büyümesi gerekiyorsa, sadece veritabanına eklemek ve dizideki ekstra verileri işlemek için kodu değiştirmek kolaydır (örneğin, koda bağlı olarak gerekli olmayabilir, örneğin verileri bir dizinin üst sınırını kullanarak döngü için). Ayarların bir listesi ise, genellikle çok fazla olmadığı ve bir SQL deyimi kullanmaktan daha kolay ve daha hızlı olduğu için kod yazacağım. Kullanıcının değiştirebileceği bir ayarsa ve seçimi daha sonraki başlatmalar için kaydetmek istiyorsanız, kayıt defteri olarak kullanmak için bir tablo oluşturacağım ve gerektiğinde değişkenleri ayrı ayrı çekeceğim.

Bu cevabın kabul edildiğini biliyorum ama bunu veritabanı g / Ç'lerini mümkün olduğunca azaltmaya çalıştığımız son web geliştirme mağazamda nasıl yaptığımızı paylaşmak istedim.

Sunucu tarafında, kullanabileceğimiz arama tipi veri yapılarını içeren dosyalar kullandık. Temel olarak bu, site gezintisi içindi (alt araştırmalar dahil), ancak mümkün olduğunca çok sayıda aşağı iniş ve onay kutusu için de kullandık (Devletler, Ülkeler, Kategoriler).

Aslında, tüm bu verileri veritabanından çıkardık. Müşteriye bir yönetici widget'ı verdiğimizden, bu verileri istedikleri zaman değiştirebilirler ve küçük nikel ödemeleriyle hiç uğraşmadık. Bu verilerin çoğu zaman neredeyse hiç değişmedi ancak zaman zaman değişecek.

Biz her zaman daha hızlı yükleme süreleri arıyorduk. Bu yüzden olabildiğince çok statik sunucu tarafı metin dosyaları uygulamaya karar verdik. Yönetici tarafında bu yaptık. Bir veritabanı tablosu her güncellendiğinde, karşılık gelen statik metin dosyasını yeniden oluştururuz. Bu bize çok esnek ve hızlı bir ortam sağladı.

Buna her durumda işe yaramayabilen çözümüm statik veri verilerini kodlanmış bir kodla bağlamak enum. Sorun statik mantığa (kod) bağlı dinamik verilere (veritabanı) sahip olmaktan geldiğinden, bunu ilişkilendiren bir veritabanı tablosuna sahip olarak bu bağlamayı açık (ve gevşek) hale getirin enum. Ör:

LooseDBCodeBinding (database table)
   ID : Int32 (key)
   Name : String
   HardCodedTypeID : Int32

// in code:
public enum LooseDBCodeBinding
{
   TYPE_1 = 1,
   TYPE_2 = 2,
   TYPE_3 = 3 // etc...
}

Ardından, LooseDBCodeBindingkayıt listesini kolayca görüntülemenizi sağlayan bir UI yazın ve bunları LooseDBCodeBinding enumdeğerlerle eşleştirin ("kırık" ciltleri desteklemek dahil). Daha sonra etrafında programlayabilir enumve veritabanını tablo anahtarı etrafında tasarlayabilirsiniz ve bu her iki bağlam hakkında da bilgisi olan sadece bir tablodur.