Mengapa saya tidak perlu memiliki satu meja untuk beberapa hubungan?

Dengan asumsi saya memiliki banyak hubungan dalam database saya, misalnya Store, Karyawan dan Penjualan, dan saya ingin menghubungkan pasangan dengan hubungan biner sederhana. Secara pribadi saya akan membuat tabel bernama Employee_Store dan Employee_Sale dengan kunci alami yang terdiri dari kunci asing.

Sekarang, kolega saya bersikeras membuat satu tabel untuk beberapa hubungan. Untuk contoh di atas mungkin ada tabel yang disebut EmployeeLinks:

EmployeeLinks(
    IdLink int PK, 
    IdEmployee int FK null,
    IdStore int FK null,
    IdSale int FK null,
    LinkType int not null
)

Tolong bantu saya dengan alasan yang bagus mengapa ini bukan ide yang baik. Saya punya argumen sendiri tetapi saya ingin merahasiakannya dan mendengar pendapat Anda yang tidak bias.

EDIT:

Awalnya tabel di atas tidak memiliki kunci utama (!). Karena kunci asing memungkinkan nol, maka kunci pengganti adalah satu-satunya pilihan.

Apa yang diusulkan kolega Anda sebagai kunci utama untuk tabel tautan ini?
Kolom kunci utama tidak dapat NULL tentu saja: tabel di atas tidak dapat dibatalkan.

Tidak ada pengidentifikasi baris alami (yang merupakan PK) dalam contoh di atas (kolom IDENTITAS bukan kunci utama), karena itu gagal dalam proses pemodelan apa pun . Jangan pernah berpikir tentang membuat tabel tanpa beberapa model (ERD, ORM, IDEF1X, apa pun)

Anda juga perlu PERIKSA kendala untuk memastikan Anda tidak memiliki tautan 3 arah.

Akhirnya, Anda tersesat ke wilayah bentuk normal ke-4 dan ke-5 tetapi karena alasan yang salah.

Saya tidak dapat menemukan contoh di internet: itu menunjukkan betapa bodohnya ini

Alasan praktis pertama yang bisa saya pikirkan adalah kinerja.

Dalam model "tradisional", Anda dapat memiliki indeks unik Idemployee, Idstoreatau apa pun bidangnya, dan mendapatkan performa hebat saat pencarian. Juga mudah dirawat untuk sisipan. Indeks unik membuat Anda bergabung lebih sering, yang bisa membuat banyak sangat JOINcepat.

Dalam model contoh Anda, untuk mendapatkan kinerja yang layak, Anda harus memiliki indeks bidang tunggal pada setiap bidang FK dalam tabel minimum, idealnya indeks penutup pada semua kombinasi yang akan dirujuk, yaitu:

• Karyawan / Toko
• Karyawan / Penjualan

Saya tidak yakin apa tipe tautan itu tetapi jika Anda referensi, mungkin harus diindeks.

Indeks-indeks ini perlu dipertahankan untuk setiap baris dalam tabel, terlepas dari apakah bidang tersebut diisi atau tidak. Anda dapat menambahkan filter tetapi itu juga akan menjadi rumit dengan begitu banyak kombinasi.

Ini juga akan mempersulit logika Anda. Anda harus melakukan pencarian pada employeeid, menemukan baris dengan nilai toko kosong, dan memperbarui; atau, cukup masukkan baris baru untuk setiap tautan baru, yang jenisnya mengalahkan tujuan konsolidasi bidang.

Pada dasarnya Anda akan menggunakan ruang disk LEBIH, memiliki indeks LEBIH untuk mempertahankan, dan mempersulit logika Anda pada dasarnya tanpa alasan. Satu-satunya "manfaat" adalah lebih sedikit tabel yang harus dihadapi.

Menempatkan banyak hubungan dalam satu tabel dapat bermanfaat jika hubungan tersebut memiliki atribut yang sama dan / atau jika Anda ingin menggabungkan data lebih dari beberapa hubungan.

Diperlukan jika jenis hubungan didefinisikan oleh pengguna saat runtime. Namun ini jarang benar-benar terjadi.

Dalam contoh Anda, hubungan tidak membagikan atribut, hubungan itu bahkan merujuk dua tabel yang berbeda. Ini membuatnya sulit untuk menegakkan kendala dan desain juga kurang intuitif.

Saya hanya akan memilih desain itu jika membuat tabel benar-benar membutuhkan biaya.