Apa praktik terbaik tentang tabel pencarian di database relasional?

Tabel pencarian (atau tabel kode , seperti beberapa orang menyebutnya) biasanya merupakan kumpulan nilai yang mungkin diberikan untuk kolom tertentu.

Misalnya, kita memiliki tabel pencarian yang dipanggil party(dimaksudkan untuk menyimpan informasi tentang partai politik) yang memiliki dua kolom:

• party_code_idn, yang memegang nilai numerik yang dihasilkan sistem, dan (tidak memiliki makna domain bisnis ) berfungsi sebagai pengganti untuk kunci asli.
• party_code, adalah kunci nyata atau “alami” dari tabel karena mempertahankan nilai yang memiliki konotasi domain bisnis .

Dan mari kita katakan bahwa tabel tersebut menyimpan data yang berikut:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

The party_codekolom, yang menjaga nilai-nilai 'Republik' dan 'Demokrat', menjadi kunci nyata dari meja, diatur dengan kendala UNIK, tapi saya opsional menambahkan party_code_idndan didefinisikan sebagai PK dari tabel (meskipun, secara logis berbicara , party_codedapat berfungsi sebagai KUNCI UTAMA [PK]).

Pertanyaan

Apa praktik terbaik untuk menunjuk ke nilai pencarian dari tabel transaksi ? Haruskah saya membuat referensi FOREIGN KEY (FK) baik (a) langsung ke nilai alami dan bermakna atau (b) untuk nilai pengganti?

Opsi (a) , misalnya,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

memiliki sifat-sifat berikut ¹ :

1. Dapat dibaca untuk pengguna akhir (+)
2. Mudah untuk mengekspor-impor lintas sistem (+)
3. Sulit untuk mengubah nilai karena perlu modifikasi di semua tabel referensi (-)
4. Menambahkan nilai baru tidak mahal (=)

Saya pikir itu hampir seperti " lewat nilai ", untuk menarik analogi dari panggilan fungsi dalam jargon pemrograman aplikasi.

Opsi (b) , misalnya,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

memiliki sifat di bawah ini:

1. Tidak dapat dibaca untuk pengguna akhir (-)
2. Sulit untuk mengimpor-ekspor karena kita perlu melakukan de-referensi (-)
3. Mudah untuk mengubah nilai, karena kami hanya menyimpan referensi dalam tabel transaksi (+)
4. Menambahkan nilai baru tidak mahal (=)

Ini sangat mirip dengan " pass by reference ", jika membandingkan dengan panggilan fungsi dalam bahasa pemrograman aplikasi.

Impor-Ekspor juga dapat dilakukan dengan cara yang berbeda, yaitu hanya dengan mengisi tabel pencarian lagi dan kemudian menabur kembali kolom pengganti. Saya harap saya mendapatkan ini dengan benar, ini adalah sesuatu yang baru saja saya dengar sebagai suatu kemungkinan.

_{1. Catat itu +, -dan =tunjukkan manfaat dari properti tersebut.}

Pertanyaan

Cukup penting: Apakah ada perbedaan antara tabel pencarian (atau kode ) dan referensi FK jika kita hanya akan menggunakan pendekatan yang terakhir? Saya pikir mereka bekerja sama saja.

Sumber terkait

• Seberapa pentingkah Tabel Pencarian?

• Praktik Terbaik Dengan Tabel Kode Atau Pencarian

• Tabel Pencarian Praktik Terbaik Tabel DB atau Enumerasi

Oleh IDN, saya bawa Anda berarti IDENTITY, SEQUENCEatau AUTO_INCREMENTlapangan? Anda harus melihat di sini dan di sini .

Catatan, bagian 5 (Menyalahgunakan nilai Data sebagai Elemen Data) dari referensi pertama, di bawah gambar 10

Tentu saja Anda dapat memiliki tabel terpisah untuk tenaga penjualan dan kemudian referensi menggunakan kunci asing, lebih disukai dengan kunci pengganti sederhana seperti sales_person_id, yang ditunjukkan di atas.

Jadi, ahli ini berpikir bahwa Anda harus "menghormati" kunci pengganti. Ini benar-benar teknik SQL yang sangat mendasar dan seharusnya tidak menyebabkan masalah dalam SQL harian Anda. Tampaknya ada kesalahan pada gambar 10 - sales_person di SalesData harus menjadi kunci pengganti (yaitu angka), bukan teks. Saya menyimpulkan ini dari kutipan di atas.

Apa yang harus Anda hindari di semua biaya adalah godaan (sangat umum untuk programmer basis data pemula) untuk melakukan kesalahan yang diuraikan dalam bagian (1) Tabel Pencarian Umum. Ini biasa disebut pendekatan MUCK ( Massively Unified Code Key ) (bukan karena kecelakaan :-) terutama oleh Joe Celko , juga secara sarkastik dikenal sebagai OTLT - One True Lookup Table ) dan mengarah ke segala macam kesulitan. Pemrogram pemula tampaknya merasa bahwa satu kode / pencarian / tabel apa pun adalah "bersih" dan akan lebih efisien ketika tidak ada yang lebih jauh dari kebenaran.

Dari referensi kedua di atas:

Normalisasi menghilangkan data yang berlebihan, sehingga membuat tugas menegakkan integritas data menjadi jauh lebih sederhana, tetapi proses membuat MUCK adalah sesuatu yang sama sekali berbeda. seperti yang akan saya tunjukkan, lebih sedikit tabel tidak sama dengan kesederhanaan.

Anda mungkin juga ingin melihat paradigma EAV ( Entity Attribute Value ) terkait yang saya bahas di sini .

Ada pendekatan ketiga yang memiliki beberapa kelebihan dari dua opsi Anda - letakkan kode aktual di tabel kode. Maksud saya urutan karakter pendek yang menangkap esensi dari nilai penuh dan unik. Untuk contoh yang Anda berikan mungkin

Idn: 1
Name: Democrats
Code: D      (or DEM)

Kode dibawa ke dalam tabel transaksional sebagai kunci asing. Ini pendek, dapat dipahami dan agak independen dari data "nyata". Perubahan tambahan pada nama tidak akan menyarankan perubahan kode. Namun, jika Partai Republik mendeklarasikan secara massal , perubahan kode mungkin diperlukan, dengan masalah yang menyertainya yang tidak akan terjadi.

Gaya ini disebut pengkodean singkatan. Saya dapat merekomendasikan tulisan Celko tentang ini. Buku-buku Google memuat beberapa contoh. Cari "pengkodean Celko".

Contoh lain: penyandian 2 atau 3 huruf untuk negara, penyandian 3 huruf (GBP, USD, EUR) untuk kode mata uang. Singkat, menjelaskan sendiri dan tidak berubah (dan ada ISO untuk mereka).