Bagaimana saya harus mewakili tipe yang disebutkan dalam database relasional?

12

Saya sedang berupaya mengembangkan basis data relasional yang melacak transaksi yang terjadi pada perangkat yang saya kerjakan untuk perusahaan saya. Ada berbagai jenis transaksi yang dapat terjadi pada perangkat, jadi kami memiliki bidang "trans_type" di salah satu tabel catatan utama kami. Grup saya telah memutuskan untuk membuat jenis bidang ini bilangan bulat dan memperlakukannya sebagai jenis yang disebutkan. Intuisi saya memberi tahu saya bahwa lebih baik menjadikan bidang ini sebagai string agar data basis data kita lebih mudah dibaca dan digunakan. Rekan kerja saya tampaknya khawatir bahwa ini akan menyebabkan lebih banyak masalah daripada nilainya. Perbandingan string itu terlalu mahal dan kemungkinan kesalahan pengetikan terlalu besar.

Jadi, menurut Anda, ketika berhadapan dengan bidang dalam basis data relasional yang pada dasarnya merupakan nilai yang disebutkan, apakah itu keputusan desain yang lebih baik untuk menjadikan bidang ini bilangan bulat atau string? Atau adakah alternatif lain yang saya abaikan?

Catatan: tipe enumerasi eksplisit tidak didukung oleh database yang kami gunakan. Dan perangkat lunak yang kami kembangkan yang akan berinteraksi dengan basis data ini ditulis dalam C ++.

database-design relational-database c.hughes
sumber
Apakah itu menyerang orang lain karena sudah lama tertunda untuk membuatnya menjadi definisi tipe yang dicentang di buat tabel? Sesuatu seperti: CREATE TABLE hit (ip varchar (40), ip_class ENUM (0, "IPv4", 1, "IPv6")); Itu harus memungkinkan Anda untuk memeriksa = <dan> dengan baik ordinal atau string (yang memetakan ke ordinal).
dlamblin

Jawaban:

26

Jenis yang disebutkan harus berupa tabel terpisah di basis data Anda yang memiliki nomor id dan nama string dan kolom lain yang mungkin berguna bagi Anda. Kemudian setiap jenis ada sebagai baris dalam tabel ini. Kemudian di meja Anda, Anda mencatat transaksi, bidang "trans_Type" harus menjadi kunci asing ke kunci tabel referensi itu. Ini adalah praktik standar dalam normalisasi basis data.

Dengan cara ini Anda telah menyimpan satu string nama resmi, bisa menggunakan perbandingan angka untuk kinerja, dan memiliki integritas referensial bahwa setiap transaksi memiliki tipe yang valid.

Ryathal
sumber
1
Ya dan jika Anda memutuskan untuk mengubah 'O' menjadi 'Open' Anda hanya perlu mengubah satu baris.
Daniel Kaplan
+1. tabel int / string sederhana adalah cara terbaik untuk merepresentasikan enum dalam db relasional.
mike30
Mungkin, pengunjung berikutnya yang mencari solusi Java menemukan itu berguna
Jauhien
2
Ini. Untuk kredit tambahan - jika tim dev telah mendefinisikan bilangan bulat dalam Java / C # enum atau yang serupa, Anda dapat menulis tes yang memeriksa apakah definisi kode enum telah berbeda dari tabel pencarian. Selalu ada bahaya bahwa menambahkan elemen di luar urutan dapat mengetuk hal-hal tidak sinkron dan Anda tidak menyadari sampai rekaman data langsung terlihat salah.
Julia Hayward
4

Praktik yang umum adalah membuat trans_typestabel, dan kemudian minta referensi tabel utama Anda dengan nama kunci asing trans_type_id. Ini memastikan bahwa catatan Anda hanya akan merujuk jenis enumerasi yang valid.

Contoh:

trans_type
----------
  Indo
  nama

transaksi
------------
  Indo
  trans_date
  detail
  trans_type_id (FK ke trans_type.id)

Contoh Data:

trans_type

ID | NAMA
----------
1 | KIRIMKAN
2 | MEMBATALKAN


transaksi

ID | trans_date | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2
FrustratedWithFormsDesigner
sumber
3

Jika nilai-nilai tersebut datang ke database sebagai bilangan bulat, simpan dengan cara itu. Tidak perlu untuk mengubah konversi menjadi string saat menulis ke database. Anda selalu dapat berhubungan dengan tabel pencarian dengan nilai string / teks (Lebih Normalisasi).

Ini memiliki keuntungan tambahan untuk memperbarui nilai string di satu lokasi daripada menjalankan semacam rutinitas pembaruan. Alih-alih 1 = 'Merah' itu bisa sama dengan 'Sangat Merah'

Ini tidak ideal untuk melaporkan kinerja dibandingkan dengan hanya membutuhkan satu tabel dengan nilai string (Dinormalisasi). Indeks pada bidang ini akan membuat kinerja cukup baik.

Sebagian besar RDBMS akan memungkinkan tenaga kuda yang cukup. Meskipun ide Anda untuk bisa 'membaca' tabel dalam bentuk data biasa, bergabung dengan sebuah tabel bukanlah masalah besar. Biasakan menggunakan tampilan atau objek serupa.

JeffO
sumber
2

Saya harus tidak setuju dengan jawaban lain untuk pertanyaan ini yang menganjurkan pendekatan tabel enumerasi terpisah.

Namun, saya tentu saja tidak mengulangi apa yang telah dikatakan, jadi saya hanya akan merujuk pada jawaban yang diterima untuk (kurang lebih) pertanyaan yang sama tentang Stack Overflow: /programming//a/229919 / 114626

Eyal Roth
sumber
+1 untuk jawaban yang tertaut. Untuk pertanyaan ini, jawaban tertaut Anda tampaknya yang benar. Tetapi tentu saja, jika penanya menginginkan fleksibilitas dalam jenis yang disebutkan maka tabel referensi akan jauh lebih baik.
Harke