Menyimpan enum dan tabel dalam sinkronisasi


11

Saya sedang membuat sebuah program yang akan memposting data ke database, dan saya telah menemukan suatu pola yang saya yakin sudah familiar: Tabel pendek dari nilai-nilai tetap yang kemungkinan besar (sangat mungkin) yang berfungsi sebagai enum. Jadi anggaplah tabel berikut bernama Status:

  Status
  Deskripsi Id
  --------------
   0 Tidak diproses
   1 Tertunda
   2 Diproses
   3 Kesalahan

Dalam program saya, saya perlu menentukan ID status untuk tabel lain, atau mungkin memperbarui catatan dengan ID status baru.

Saya bisa membuat kode status Id dalam enum dan berharap tidak ada yang mengubah database. Atau aku bisa mengambil pra-nilai berdasarkan deskripsi (sehingga hardcoding yang bukan).

Apa yang akan menjadi pendekatan yang tepat untuk menjaga keduanya, enum dan tabel, disinkronkan?


Mengapa Anda menjaga semuanya tetap selaras dan tidak sinkron? Sinkronisasi (katakan itu) aneh!
MrFox

1
@suslik Keduanya diucapkan sama. Sinkronisasi dan Sinkronisasi .
MPelletier

1
Memiliki enum dan tabel database adalah duplikasi. Kecuali jika tabel database digunakan oleh aplikasi lain, saya akan meninggalkan tabel dan hanya menggunakan enum. Jika tabel akan digunakan di beberapa aplikasi, muat status dari database saat runtime.
Peter Smith

Itu tergantung pada konteksnya. Dalam hal ini, sebagai nilai alur kerja atau status tugas, saya cenderung lebih suka membuatnya lebih dinamis daripada statis, karena proses sering cenderung berubah; dan cenderung berubah dari band untuk jadwal rilis perangkat lunak. Di sisi lain, jika ini adalah layanan stabil yang tidak mungkin memiliki status baru yang diperkenalkan atau dihapus yang sudah ada, saya mungkin lebih terdorong untuk membuat hard-kode enum / denormalize mereka (tergantung pada bagaimana catatan digunakan nanti).
JustinC

@PeterSmith Basis data tidak dapat menegakkan batasan jika mereka hanya ada di Java enum Anda dan bukan di tabel. Anda akan membatasi nilai dalam basis data Anda, bukan?
David Conrad

Jawaban:


5

Saya akan membuat kode enum dalam program Anda, karena saya curiga status yang berbeda ini memengaruhi logika program Anda. Jika Anda memiliki status baru, bagaimana seharusnya program Anda bereaksi terhadap status baru ini?

Karena basis data adalah bagian dari aplikasi Anda, saya pikir tidak masuk akal untuk memengaruhi satu tanpa berkonsultasi dengan yang lain, seperti berbicara.


Ini bukan tentang status baru (yang pasti akan menjamin modifikasi baik database dan program), tetapi nilai-nilai Id.
MPelletier

2
Saya tidak mengerti mengapa Anda akan mengubah nilai ID tanpa mengubah artinya. Pencacahan semacam ini tidak akan bertambah secara otomatis, dan ini benar-benar hanya untuk keterbacaan bagi orang-orang yang melakukan debug basis data, karena biasanya aplikasi Anda akan membuat kueri, dan ia sudah tahu untuk apa ID pendingitu nantinya. Tentu saja memiliki Statusmeja memberi Anda integritas referensial, tetapi itulah yang ingin saya sampaikan.
Matius

Ya, itulah idenya. Tetapi jika saya mengatur ID ke satu tempat ke tempat lain, saya bekerja dengan asumsi bahwa keduanya benar. Itu tautan yang longgar, bukan?
Anggota parlemen

3
Kami membuat asumsi ini setiap saat, jika Anda memikirkan definisi tabel, program kami mengasumsikan definisi tersebut seperti saat menulis kueri. The Statustabel tidak harus dianggap dinamis melalui runtime aplikasi, dan dengan demikian saya tidak berpikir Anda harus membacanya seperti itu.
Matius

8

Saya biasanya memuat data ini ke cache statis (biasanya dalam HashMap atau sesuatu seperti itu) ketika aplikasi dijalankan. Ini menghindari keharusan mengkompilasi ulang hanya karena enum telah dimodifikasi dalam beberapa cara.


2

Karena itu adalah status, mereka harus dikodekan ke dalam aplikasi untuk memastikan tidak ada perubahan DB yang akan merusak program Anda (setidaknya tidak mudah). Ini penting karena setiap status yang harus ditambahkan harus dikodekan terlebih dahulu dan tidak hanya ditambahkan ke DB.

Anda masih harus memiliki nilai status yang ditulis ke DB dengan uraian yang benar jika Anda perlu menarik laporan misalnya.

Biasanya saya memiliki snipet kode kecil yang akan terhubung ke DB dan memverifikasi bahwa status yang tercantum dalam tabel tertentu semua memiliki nilai id / nama yang sama dengan yang saya simpan dalam memori. Jika tidak cocok saya akan membatalkan eksekusi perangkat lunak.

Tergantung pada kebutuhan Anda, Anda mungkin ingin menerapkan perilaku yang sedikit berbeda tetapi secara keseluruhan itu adalah ide yang baik untuk memiliki status tersebut dikodekan.


2

Kami memiliki masalah serupa pada proyek saya (kode lama, hore!) Masalah utama adalah bahwa "tabel enum tidak pernah berubah" sampai mereka melakukannya dan kode rusak. Saya memiliki dua strategi untuk memitigasi yang telah saya migrasi secara perlahan.

Pertama, dan terbaik, adalah menghilangkan referensi langsung ke nilai-nilai ini bila memungkinkan. Selalu bertanya, "mengapa saya harus langsung menggunakan nilai enum?" Dalam banyak kasus, ini adalah tanda bahwa kode memiliki terlalu banyak asumsi kode keras atau mencoba melakukan terlalu banyak manipulasi pada data. Lihat apakah Anda tidak dapat membuat hubungan yang lebih baik dalam database atau kode yang lebih fleksibel untuk menangani apa yang sedang dimanipulasi.

Ketika itu tidak berhasil, saya pergi ke rencana B: pembuatan kode. Karena tabel jarang berubah dan kami menerbitkan bangunan baru secara berkala, pembuat kode dapat membaca tabel enum dan menulis kode enum. Pustaka yang dihasilkan secara dinamis ini kemudian digunakan dalam proyek. Jika DB berubah, build berikutnya tidak akan dikompilasi, yang jauh lebih baik daripada mendapatkan kesalahan runtime misterius.


Bagaimana Anda menghilangkan referensi ke enum? Misalnya Anda menyortir atau mencari berdasarkan status dalam kasus ini. Memiliki nilai sihir dalam DB juga tidak cocok dengan saya. Itulah gunanya tabel pencarian.
nportelli

Di masa lalu, saya telah melakukan yang sebaliknya. Setiap kali ada perubahan kode di Enum, saat boot aplikasi, itu menyinkronkan nilai-nilai itu ke Database. Kode di sini adalah sumber kebenaran. Database adalah representasi dari itu. Biasanya saya mengabaikan nilai dalam DB yang tidak dapat dipahami oleh kode tetapi dengan cara ini, saya mendapatkan mekanisme untuk secara otomatis membersihkan DB jika diperlukan.
Anshul
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.