Ne zaman bir DB kullanmak yerine bir kod gerçek veri değerleri koda?

Benim için uzun süredir devam eden bir soru şuydu: Ne zaman veriyi (gerçek değerler) bir veritabanı tablosunda saklarım ve bunları ne zaman kodda saklarım?

Anlatılmamış konsensüs tipik olarak şu şekildedir (*):

Tek bir değişken veya basit bir yapı veya birkaç değerden oluşan bir dizi ise, verileri doğrudan koda koyun.

[* fikir birliği yorumlarda ve cevaplarda tartışıldı, ancak temelde soruyu hemen başlatmak için bir tür öncül istedim, bu yüzden meydan okumaktan ve geliştirmekten çekinmeyin ]

Misal:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

Aynı türde yüzlerce + veri satırı varsa, bir veritabanı kullanın.

Ama gri bir alan var gibi görünüyor; o kadar net olmayan davalar ne olacak? Karar vermek için dikkat edilmesi gereken hususlar ve faktörler nelerdir?

Örnek:
Şirketinizin "412T" olarak temsil edilebilecek 10-15 farklı türde motor çerçevesi kullandığını varsayalım. Yaklaşık 30 taneniz var ve nadiren değişiyorlar. Bunlar için bir DB tablosu oluşturabilir veya bir veritabanında sabit kod yazabilirsiniz. Bu durumda, motorlar sık ​​sık değişmesi muhtemel olmayan statik, fiziksel şeylerdir.

Onları kodda tutmak, onları veritabanında DB değişikliklerinin izlenmediği kaynak denetimine tabi tutar. Ancak bunları bir veritabanında tutmak, kodu verilerden kurtarır (ayırır).

Kullanabileceğim başka bir (gerçek) örnek, bu sorum: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (şu anda 48 seçenek verisi satırları).

Bu iki ifade gerçekten ne zaman sabit kod verileri hakkında bir fikir birliğini temsil sanmıyorum:

Tek bir değişken veya basit bir yapı veya birkaç değerden oluşan bir diziyse, verileri doğrudan koda koyun

Aynı türde yüzlerce + veri satırı varsa, bir veritabanı kullanın

Basit karşı örnek (daha iyi olanlar olduğundan eminim): programlama dili sözdizimi tabloları, genellikle sabit kodlanmış karmaşık büyük yapılardır. Perl kaynak kodundan bir örneğe bakın .

Bunun yerine önce şunu sormaya odaklanacağım:

• Veriler ne sıklıkla değişir?

• Kimin değiştirmesi gerekebilir?

"Ne sıklıkta" sorusunun cevabı "uygulamamın yeni bir sürümünü dağıtmak istediğimden" daha sıksa, verileri sabit kodlamamalısınız.

"Bunu kim değiştirir" sorusunun yanıtı "programcı dışında herhangi biri" ise, verileri kodlamamalısınız.

Küçük bir dükkanda, kodlayıcı ve kullanıcı arasındaki ayrım ortadan kalkmış ve "dağıtım" fikri de ortadan kalkmıştır. Bu durumda kendi alan adınızın kralısınız ve ne isterseniz yapabilirsiniz.

Ancak bu durumda bile, işbirliği yapma ihtiyacı ortaya çıkabilir ve özel bir uygulama, programcıların genellikle takip ettiği bir sözleşmeye uymazsa bu zor olabilir.

Üçüncü seçenekle giderdim: bir yapılandırma dosyası!

Üzerinde çalıştığım uygulamalar için (Java'da, tüm örneklerim Java + Spring kullanıyor), bu değerler genellikle yapılandırma dosyalarında saklanır ve uygulama başlatıldığında onlara gereken koda enjekte edilir (Spring aracılığıyla). Özellikler dosyasında:

motorFramesString=412T, 413T, ...

İlkbahar konfigürasyonunda:

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

Bunun avantajı, bu çoğunlukla statik değerlerin çoğunu, yeniden derleme yapmadan kolayca değiştirebilmeniz veya daha fazla ekleyebilmeniz ve (ilişkisel) veritabanınızı referans verileriyle doldurma konusunda endişelenmenize gerek olmamasıdır ( endişe ve belki her şey ihtiyaçları ) zaten veritabanında olmak.

Bu değerlerin neden bir referans tablosu yerine bir yapılandırma dosyasına girmesi gerektiğine gelince : Bu değerleri çoğunlukla kodda mı yoksa çoğunlukla veritabanında mı kullanmayı planlıyorsunuz? Bu değerlere bağlı birçok mevcut sorgunuz, görünümünüz ve prosedürünüz varsa, bunları yapılandırma verilerine yüklemek ve olası her sorguya parametre olarak göndermekten daha kolay olduğu için bunları veritabanına referans veri olarak koymak en iyisi olabilir. bunlara gönderme yapan prosedür / prosedür. Değerler çoğunlukla uygulama kodunda kullanılırsa, yapılandırma dosyası muhtemelen daha iyi bir seçimdir.

Bağladığınız özellikler gibi daha karmaşık bir örnek, özellikleriyle veya dışarı özellikleriyle de yapılabilir.

Ürünlerde. Özellikler:

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

İlkbahar yapılandırma dosyanızda:

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

Bununla ilgili güzel bir şey, kaynak verileriniz bir elektronik tablo ise (bağlandığınız soruda olduğu gibi) özellikleri ve yaylı snippet'leri otomatik olarak oluşturmak için Excel'deki makroları kullanabilmenizdir.

Sorunun önermesinin tam olarak doğru olmadığını düşünüyorum. Bölünmesi faktör değildir miktar kayıtlarının bu değişikliğe ihtiyacı, ancak frekans yanı sıra değişikliklerin kim onları değiştirir.

Sıklık

Veriler geçici olduğunda , yazılımın sık sık ve serbest bırakılma döngüsünün dışında değiştiği için, sabit kodlanmış değerlerin veya hatta yapılandırma dosyalarının dışında yapılandırılabilmesi gerekir. Özellikle uygulamanın kendisi bunu koruyabiliyorsa, bir veritabanı burada anlamlıdır.

Kim

Bir müşterinin verileri değiştirmesi gerektiğinde, kullanıcı dostu bir şekilde ve bir yayın döngüsünün dışında değiştirilebilir olması gerekir.

Ortak Konu

Buradaki ortak iş parçacığı, verilerin bir yazılım sürümünün dışında değiştirilmesi gerektiğinde, bir veritabanında saklanması gerektiğidir. Bir sürüm sırasında veritabanları yükseltilebilir, ancak veriler sıfırlanmadan veya yoğun bir şekilde değiştirilmeden devam eder. Bir müşterinin verileri değiştirmesi (veya işlevselliği yapılandırması) gerektiğinde, aptal geçirmez güzel bir ön ucu olan bir veritabanında saklanmalıdır.

Test yapmak

Yazılımınızı çeşitli yapılandırmalarda doğrulayan birim testleri yazdığınızdan emin olun. Belki müşteriniz isteğe bağlı bir istem açar veya bir metreyi on iki aya eşit olacak şekilde yeniden tanımlar. Değişikliğin ne kadar makul olduğuna bakılmaksızın, yazılımınız izin veriyorsa, ne kadar yetersiz olursa olsun, değişikliğin beklendiği gibi çalıştığını doğrulamak daha iyidir.

Ne değişikliklerin sıklığı ne de verilerin nerede saklanacağına karar veren veri miktarıdır.

Programı çalıştırmak için veri gerekiyorsa, program kodunun bir parçasıdır, bu yüzden sabit olarak saklayın. Diğer tüm veriler veritabanına gider.

Elbette, yapılandırma dosyaları, görüntüler, sesler, vb. Genellikle dosya sisteminde daha iyi saklanır.

En ufak bir şansınız olsa bile, sabit kodlanmış bir şey değiştiği için bir uygulamayı yeniden oluşturmanızla sonuçlanan bir telefon görüşmesi alacaksınız, o zaman zor kodlamayın. En azından bir yapılandırma dosyasında veya db tablosunda saklayın. Mutlaka korumak için herhangi bir UI sağlamanız gerekmez, ancak bir yapılandırma dosyasını çevirmek ve değiştirmek veya bir tablo üzerinde SQL UPDATE çalıştırmak, tüm çekim eşleşmesini yeniden oluşturmak için kesinlikle tercih edilir.

Ayrım aslında biraz gri bir alan ama bu tür konulara yaklaşımım şu: üretimde veri değişiyor mu? "Bir üretim ortamında konuşlandırmadan sonra değişen her şey, nadiren değişebilen şeyler için bile veritabanına gitmelidir.

Yani sormanız gereken soru "ne sıklıkta değişecek?" Değil, "değişebilir mi?". Bir özelliğin değeri , üretim ortamında aynı kod yinelemesinde ( kodda başka bir şeye dokunmadan) değişebilirse , veritabanına gider.

Ayrıca eksik olan "program kontrolü" türü bilgileri maksimum arabellek boyutu, bir sırada yüksek sesle öğe sayısı, bir ekran için maksimum sayfa boyutu her zaman programda ya da bir yapılandırma dosyasında sabit kodlanmış daha iyi olduğunu söylüyor.

Bu tür verileri bir veritabanında tutarsanız, her zaman birisinin verileri anında değiştirme ve bir sistemin davranışını tamamen değiştirme olasılığı vardır.

Diğer sorun ise, kullanmanız gereken kaynak kontrolü / değişiklik yönetimi / otomatik derleme sistemleri aracılığıyla veritabanı girişleri almanın kolay bir yolu olmamasıdır.

Veritabanında asla tutmamanız gereken bir şey, veritabanına erişmek için gereken ayrıntılardır.
Sonuçta aynı veritabanının bağlantı dizelerini, kullanıcı adını ve parolasını almak için veritabanına erişmeniz gerekiyorsa, bir catch-22'ye sahip olursunuz.

Sabit kodlu mu? hmm, uygulamayı yükleyen ve uygulama ile birlikte gelen bir çeşit veritabanı kullanıyorsanız işe yarayabilir.
Yapılandırma dosyası? Daha umut verici ama ya hesap güvenliği?

Tabii ki veritabanı bilgilerini bu yapılandırma dosyasında şifrelenmiş biçimde saklayabilirsiniz, ancak daha sonra şifre çözme anahtarlarının bir yerde saklanması gerekir ve bu neredeyse kesin olarak kodlanır.

Bunun dışında asla değişmeyen şeyler var. Doğal sabitler (G, pi, e, adını siz koyun) gibi şeyler, e-posta doğrulaması gibi bazı normal ifadeler gibi şeyler olabilir.