Kapan satu hard-code data aktual nilai ke dalam kode yang bertentangan dengan menggunakan DB?

Pertanyaan lama bagi saya adalah: kapan saya menyimpan data (nilai aktual) dalam tabel database, dan kapan saya menyimpannya langsung dalam kode?

Konsensus yang tak terhitung biasanya adalah (*):

Jika itu adalah variabel tunggal atau struktur sederhana, atau array dari beberapa nilai, letakkan data dalam kode.

[* konsensus telah diperdebatkan dalam komentar dan jawaban, tetapi pada dasarnya saya ingin semacam premis untuk memulai pertanyaan, jadi jangan ragu untuk menantang dan memperbaikinya ]

Contoh:

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

Jika memiliki ratusan baris data dengan tipe yang sama, gunakan database.

Tapi sepertinya ada area abu-abu; bagaimana dengan kasus-kasus yang tidak begitu jelas? Pertimbangan dan faktor apa yang perlu diperhatikan untuk membuat keputusan?

Contoh:
Katakan perusahaan Anda menggunakan 10-15 jenis kerangka motor yang dapat direpresentasikan sebagai "412T". Anda memiliki sekitar 30 dari mereka dan mereka jarang berubah. Anda bisa membuat tabel DB untuk mereka atau kode keras mereka dalam database. Dalam hal ini, motor bersifat statis, hal-hal fisik yang cenderung tidak sering berubah.

Menjaga mereka dalam kode menjadikannya sumber kendali, di mana dalam database, perubahan DB biasanya tidak dilacak. Tetapi menyimpannya dalam basis data membebaskan (memisahkan) kode dari data.

Contoh (aktual) lain yang dapat saya gunakan adalah pertanyaan saya ini: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (saat ini 48 deretan data opsi).

Saya tidak berpikir dua pernyataan ini benar-benar mewakili konsensus tentang kapan harus memasukkan data kode:

Jika itu adalah variabel tunggal atau struktur sederhana, atau array dari beberapa nilai, letakkan data di kode

Jika memiliki ratusan baris data dengan tipe yang sama, gunakan database

Contoh-contoh sederhana (saya yakin ada yang lebih baik): tabel sintaksis bahasa pemrograman adalah struktur besar yang kompleks yang sering kali dikodekan dengan keras. Lihatlah contoh dari kode sumber Perl .

Alih-alih, saya akan fokus dulu pada bertanya:

• Seberapa sering data berubah?

• Siapa yang mungkin perlu mengubahnya?

Jika jawaban untuk "seberapa sering" adalah "lebih sering daripada yang saya inginkan untuk menyebarkan versi baru aplikasi saya," maka Anda tidak harus membuat kode data.

Jika jawaban untuk "siapa yang mengubahnya" adalah "siapa pun selain programmer," maka Anda seharusnya tidak membuat kode data.

Di sebuah toko kecil, ada kemungkinan perbedaan antara pembuat kode dan pengguna telah menghilang, dan gagasan "penyebaran" juga telah menghilang. Dalam hal ini Anda adalah raja domain Anda sendiri dan Anda dapat melakukan apa pun yang Anda suka.

Tetapi bahkan dalam situasi itu, kebutuhan untuk berkolaborasi dapat muncul, dan itu bisa sulit jika aplikasi kustom tidak mengikuti konvensi yang biasanya diikuti oleh programmer.

Saya akan memilih opsi ketiga: file konfigurasi!

Untuk aplikasi yang saya kerjakan (di Jawa, jadi semua contoh saya menggunakan Java + Spring), nilai-nilai seperti itu biasanya disimpan dalam file konfigurasi dan disuntikkan (melalui Spring) ke dalam kode yang membutuhkannya ketika aplikasi dijalankan. Dalam file properti:

motorFramesString=412T, 413T, ...

Di konfigurasi pegas:

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

Keuntungan dari ini adalah bahwa Anda dapat mengubah atau menambahkan lebih banyak dari nilai-nilai sebagian besar-statis ini dengan cukup mudah, tanpa kompilasi ulang, dan Anda tidak perlu khawatir mengisi database (relasional) Anda dengan data referensi (karena itu tampaknya merupakan perhatian, dan mungkin tidak semua yang perlu dalam database)

Adapun mengapa nilai-nilai ini harus masuk ke file konfigurasi bukan tabel referensi: Apakah Anda berencana untuk menggunakan nilai-nilai ini sebagian besar dalam kode, atau sebagian besar dalam database? Jika Anda memiliki banyak kueri, tampilan, dan prosedur yang bergantung pada nilai-nilai ini, mungkin lebih baik memasukkannya ke dalam basis data sebagai data referensi, karena lebih mudah daripada memuatnya dari file konfigurasi dan mengirimkannya sebagai parameter untuk setiap kueri yang mungkin / lihat / prosedur yang merujuk mereka. Jika nilai sebagian besar digunakan dalam kode aplikasi, maka file konfigurasi mungkin merupakan pilihan yang lebih baik.

Contoh yang lebih rumit seperti apa yang Anda tautkan dapat dilakukan juga, dengan atau tanpa properti.

Dalam produk. Properti:

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

Dalam file konfigurasi pegas Anda:

<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>

Yang menyenangkan tentang ini adalah bahwa jika data sumber Anda adalah spreadsheet (seperti dalam pertanyaan yang Anda tautkan), Anda bisa menggunakan makro di Excel untuk secara otomatis menghasilkan properti dan pegas cuplikan.

Saya pikir premis pertanyaannya kurang tepat. Faktor pemisah bukanlah jumlah catatan yang perlu diubah, tetapi frekuensi perubahan serta siapa mengubahnya.

Frekuensi

Ketika data volatile , dalam arti bahwa itu sering berubah dan di luar siklus rilis perangkat lunak, itu harus dapat dikonfigurasi di luar nilai-nilai hard-coded atau bahkan file konfigurasi. Database masuk akal di sini, terutama jika aplikasi itu sendiri mampu memeliharanya.

Siapa

Ketika seorang pelanggan harus dapat mengubah data, itu harus dapat dimodifikasi dengan cara yang ramah pengguna dan di luar siklus rilis.

Utas umum

Utas umum di sini adalah bahwa ketika data perlu diubah di luar rilis perangkat lunak, itu harus disimpan dalam database. Basis data mungkin ditingkatkan selama rilis, tetapi data tetap hidup tanpa disetel ulang atau banyak dimodifikasi. Ketika seorang pelanggan harus dapat mengubah data (atau mengkonfigurasi fungsi), itu harus disimpan dalam database dengan ujung depan yang bagus yang idiot-proof.

Pengujian

Pastikan untuk menulis unit test yang memvalidasi perangkat lunak Anda dalam berbagai konfigurasi. Mungkin pelanggan Anda menyalakan prompt opsional, atau mengubah satu meter menjadi sama dengan dua belas kaki. Terlepas dari seberapa masuk akal perubahan itu, jika perangkat lunak Anda memungkinkan, sebaiknya memvalidasi bahwa perubahan itu berfungsi seperti yang diharapkan tidak peduli seberapa gila itu.

Bukan frekuensi perubahan atau jumlah data yang memutuskan di mana menyimpan data.

Jika data diperlukan untuk menjalankan program, itu adalah bagian dari kode program, jadi simpan sebagai konstanta. Semua data lain masuk dalam database.

Tentu saja, file konfigurasi, gambar, suara, dll biasanya lebih baik disimpan di sistem file.

Jika ada kemungkinan sekecil apa pun Anda akan mendapatkan panggilan telepon yang mengakibatkan Anda harus membangun kembali aplikasi karena sesuatu yang kode-keras telah berubah, maka jangan membuat-kode itu. Paling tidak simpanlah dalam file config atau tabel db. Anda tidak harus menyediakan UI apa pun untuk memeliharanya, tetapi memutar dan mengubah file konfigurasi atau menjalankan SQL UPDATE di atas meja tentu saja lebih baik daripada membangun kembali seluruh pertandingan pemotretan.

Perbedaannya memang agak abu-abu, tetapi pendekatan saya untuk masalah seperti ini adalah: apakah data berubah dalam produksi "? Apa pun yang berubah setelah ditempatkan di lingkungan produksi harus masuk dalam database, bahkan untuk hal-hal yang jarang berubah.

Jadi pertanyaan yang harus Anda ajukan bukanlah "seberapa sering itu akan berubah?", Tetapi "bisakah itu berubah?". Jika nilai untuk properti dapat bervariasi dalam iterasi kode yang sama (tanpa menyentuh apa pun dalam kode) pada lingkungan produksi, itu masuk ke dalam database.

Apa yang Anda juga hilang adalah "kontrol program" ketik informasi mengatakan ukuran buffer maksimum, jumlah item dengan keras dalam suatu urutan, ukuran halaman maksimum untuk layar selalu lebih baik baik dikodekan dalam program atau dalam file konfigurasi.

Jika Anda menyimpan data seperti ini di dalam basis data, selalu ada kemungkinan seseorang mengubahnya dengan cepat dan sepenuhnya mengubah perilaku sistem.

Masalah lainnya adalah tidak ada cara mudah untuk mendapatkan entri basis data melalui kontrol sumber / manajemen perubahan / sistem pembangunan otomatis yang seharusnya Anda gunakan.

Satu hal yang tidak boleh Anda simpan dalam database adalah detail yang diperlukan untuk mengakses database.
Anda memiliki sedikit tangkapan-22 jika Anda perlu mengakses database untuk mengambil string koneksi, nama pengguna, dan kata sandi untuk database yang sama.

Hardcode itu? hmm, mungkin berfungsi jika Anda menggunakan semacam basis data yang menginstal dan dikirimkan bersama aplikasi.
File konfigurasi? Lebih menjanjikan tetapi bagaimana dengan keamanan akun?

Tentu saja Anda dapat menyimpan informasi basis data dalam file konfigurasi dalam bentuk terenkripsi, tetapi Anda harus menyimpan kunci dekripsi yang disimpan di suatu tempat, dan itu pasti akan sulit di-kode.

Terlepas dari itu, ada hal-hal yang tidak pernah berubah. Hal-hal seperti konstanta alami (G, pi, e, sebut saja), hal-hal yang mungkin seperti ekspresi reguler tertentu, seperti validasi email.