Panduan untuk menggunakan kunci komposit untuk mengidentifikasi baris

Apakah ini praktik yang baik (atau akankah ada efek buruk) menggunakan seperangkat 4 kolom untuk mengidentifikasi baris sebagai unik (satu menjadi kunci foriegn, tiga lainnya merupakan tipe data float)? Saya mencoba membangun tabel yang (dengan 4 tombol ditautkan) akan menggambarkan entri unik dalam tabel. Saya ingin tahu apakah ini rencana serangan yang bagus atau apakah ada cara yang lebih baik.

Untuk tujuan visual, gambar tabel berikut. Kami memiliki item inventaris yang disusun seperti tabel berikut: ( [K]adalah simbol kunci utama, garisnya adalah hubungan)

    Sheet_Class        Sheet_Type         Sheet_Size
    ===========        ==========         ==========
[K] Sheet_Class-.  [K] Sheet_Type--.  [K] Sheet_Size
                 '---- Sheet_Class  '---- Sheet_Type
                                          Length
                                          Width
                                          Thickness

Data dapat ditampilkan dengan cara berikut, tetapi untuk singkatnya saya telah mengecualikan membawa kolom terkait:

 Sheet_Class    Sheet_Type    Sheet_Size                        (Tables)
[Sheet_Class]  [Sheet_Type]  [Length], [Width], [Thickness]     (Column Values)
=============  ============  ==============================

Aluminum
               5052-H32
                             48, 96, 0.032
                             48, 96, 0.040
                             48, 96, 0.063

               6061-T6
                             60, 120,0.032
                             60, 120,0.040
                             60, 120,0.063

Steel
               1018-CRS
                             48, 96, 0.018
                             48, 96, 0.023
                             48, 96, 0.031

Seperti berdiri (dan saya telah menunjukkan dalam "skema" saya di atas), saya menggunakan kunci primer integer sederhana (kenaikan otomatis) untuk entri dalam tabel Sheet_Size . Namun, saya ingin tahu apakah lebih baik menggunakan kombinasi kolom Sheet_Type , Panjang , Lebar , & Ketebalan ? Mengingat setiap entri dalam Sheet_Size harus berbagi semua kualitas unik ini, dan bahwa bidang penambahan otomatis tidak akan menunjukkan ini dengan cukup baik, apakah ini rute terbaik untuk diambil?

Jika saya tidak menjelaskan situasinya dengan cukup baik, beri tahu saya. Saya menemukan diri saya perlu untuk memecahkan bagian-bagian ini (Kelas vs Tipe vs Ukuran stok aktual) dari bahan yang diinventarisasi untuk tujuan logika lain, tetapi saya siap untuk umpan balik jenis apa pun.

Bimbingan apa pun akan dihargai.

Pembaruan (08-12-2011)

Setelah jawaban diposting, saya memutuskan untuk melakukan kombinasi jawaban Mark & jawaban X-Zero . Saya memutuskan itu ide bagus untuk menempatkan batasan unik pada kolom panjang, lebar dan tebal, tapi saya juga suka ide membagi ukuran material ke baris unik dan menghubungkannya dengan suatu hubungan.

Sayangnya saya tidak dapat menerima kedua jawaban tersebut, jadi saya akan menerima X-Neros untuk mengambil (apa yang saya rasakan) menjadi lebih kritis pada masalah dan menawarkan penyesuaian skema.

Terima kasih semuanya atas jawaban Anda.

Setelah memikirkan hal ini, saya akan merevisi struktur meja Anda hanya sedikit.
Pertama, revisi tabel ukuran lembar Anda:

Sheet_size
===========
Id
Length
Width
Thickness

Kedua, buat tabel hubungan ukuran lembar / jenis:

Sheet_size_type
================
Sheet_Type_Id
Sheet_Size_Id

Lalu, buat batasan berikut:

1. Kunci utama (dan indeks) Sheet_sizeharus berupa kolom id
2. Seharusnya ada semacam kunci unik (dan indeks) yang diterapkan pada dimensi di Sheet_size. Pertimbangkan, apakah dua lembar dimensi (48, 96, .5) dan (96, 48, .5) sama (yaitu, apakah arah dimensi itu penting)? Masalah semacam ini mungkin sulit ditegakkan jika melalui penggunaan kolom sebagai bagian dari kunci utama, tetapi menjadi lebih mudah dikelola ketika menggunakan kendala dan prosedur tersimpan.
3. Kunci utama (dan indeks) Sheet_size_typeharus menggunakan kedua kunci asing, dimulai dengan kunci utama yang lebih rendah (mungkin sheet_type, berikan contoh Anda). Anda mungkin menginginkan indeks tambahan di arah lain, tetapi mungkin tidak perlu.

Revisi ini akan menghemat ruang basis data Anda (sebagai perbandingan jumlah jenis lembar menggunakan ukuran yang sama), dan seharusnya tidak terlalu memengaruhi overhead.

Ada potensi kekhawatiran lain tentang kesetaraan / keunikan jika Anda menggunakan floattipe data, karena ketidaktepatan dapat membuat Anda tersandung tiba-tiba. Anda harus mempertimbangkan apakah tipe titik tetap, dengan presisi tertentu, akan lebih tepat.

Tampak seperti keputusan kunci alami vs pengganti , pendapat yang berkisar dari dipertimbangkan dan praktis untuk akademik , berbatasan dengan dogma. Tergantung pada RDBMS, ada pertimbangan untuk model fisik yang dapat memiliki implikasi kinerja yang signifikan misalnya pilihan kunci berkerumun di SQL Server.

Secara pribadi, jika saya memiliki kunci kandidat atribut yang sempit dan tunggal, saya tergoda untuk menggunakannya. Kunci lebar dan / atau komposit, secara default saya menambahkan pengganti pada model. Dalam kasus Anda, saya akan memilih kolom identitas pada Sheet_Size sebagai kunci utama berkerumun dan batasan unik pada jenis / panjang / lebar / tebal.

Saya akan mengarahkan Anda sedikit ke jawaban ini dari pertanyaan sebelumnya .

Kutipan: "Mengenai cara mendesain kunci utama itu, ada dua aliran pemikiran:

• yang membuat PK sebagai kolom terpisah, biasanya dibuat sendiri, seperti GUID atau dan kenaikan otomatis INT (dalam kasus Anda, kolom pengenal unik yang terpisah);
• yang membuat PK sebagai kolom (atau kumpulan kolom) internal ke tabel (dalam kasus Anda akan menjadi nama pengguna atau email atau SSN, apa pun yang membuat pengguna itu unik) yang secara unik mengidentifikasi catatan.

Untuk apa Anda mematuhi garis, itu hanya masalah selera. "

Efek samping dari setiap solusi yang dipilih dapat berupa:

• kemungkinan menggunakan kunci majemuk di mana saja:

  • tingkatkan penyimpanan untuk semua tabel yang terlibat;
  • menambah / mempersulit indeks pada FK yang sering digunakan;
  • menyulitkan penulisan semua pernyataan bergabung Anda
  • membuat Mr. Joe Celko senang :-) (referensi tentang pendapatnya mengenai kunci alami atau buatan dapat ditemukan di sini dan di sini , dan sebagian besar di mana saja dia ditanya tentang masalah ini)

• kemungkinan menggunakan kunci yang dihasilkan:

  • sederhanakan 3 langkah sebelumnya
  • mempersulit situasi mereplikasi tabel dengan identitas PK (referensi di sini , di sini atau di sini )

Saya pribadi lebih suka kunci IDENTITAS INT dihasilkan, tetapi apa yang cocok Anda harus baik-baik saja.

Kunci komposit masuk akal. Menerapkan kunci itu memastikan bahwa atribut bisnis tidak dapat diduplikasi. Itu hal yang baik karena merekam data yang sama beberapa kali akan menyebabkan ambiguitas, ketergantungan yang tidak diinginkan dan membuat kesalahan pengguna dan data yang salah lebih mungkin terjadi.

Kunci peningkatan otomatis saja tidak akan melindungi integritas data bisnis Anda. Jika kunci penambahan otomatis tidak memiliki tujuan tertentu (misalnya sebagai target referensi kunci asing di tabel lain), maka kunci tersebut dapat dengan aman dijatuhkan.