Sebuah persyaratan baru telah muncul pada basis kode lama, yang pada dasarnya memungkinkan komunikasi langsung (internal) antara dua kelas pengguna yang sebelumnya tidak terkait langsung (disimpan dalam tabel yang berbeda dengan skema yang sama sekali berbeda dan, sayangnya, kode ini hampir tidak sadar OO, banyak kurang dirancang, jadi tidak ada kelas induk). Karena kita keluar untuk menggantung tas pada pengaturan lama ini yang tidak pernah mempertimbangkan fungsi ini, tidak ada jaminan bahwa tidak ada tabrakan PK - mengingat dataset yang digunakan, secara praktis dijamin ada ADA.
Jadi, solusinya tampak jelas: bunuh dengan api dan tulis ulang seluruh tabel pemetaan berantakan . Saya mendapatkan dua arah untuk cara-cara yang mungkin untuk mengimplementasikan peta, tapi saya bukan DBA, jadi saya tidak yakin apakah ada pro dan kontra yang saya lewatkan.
Demi memperjelas abstraksi, pertimbangkan tiga kelompok data pengguna yang berbeda: Profesor, Administrasi, Siswa (Tidak, ini bukan tugas pekerjaan rumah. Janji!)
Pemetaan 1
(professor_id, admin_id, dan student_id adalah kunci asing ke tabel masing-masing)
| mailing_id (KEY) | professor_id | admin_id | student_id |
-------------------------------------------------------
| 1001 | NULL | 87 | NULL |
| 1002 | 123 | NULL | NULL |
| 1003 | NULL | NULL | 123 |
+/- untuk pendekatan ini tampaknya cukup berat di kontra:
- Dua bidang "terbuang" per baris
- Melanggar 2NF
- Rentan untuk menyisipkan / memperbarui anomali (baris dengan hanya 0-1 bidang yang disetel NULL, mis.)
Pro bukan tanpa kemampuan mereka sendiri, meskipun:
- Pemetaan dapat dilakukan dengan pencarian tunggal
- Mudah menentukan "sumber" data untuk pengguna yang diberikan dari mailing_id
Sejujurnya, dalam perut saya, saya tidak suka ide ini sama sekali.
Pemetaan 2
(anggap MSG_ * adalah konstanta yang didefinisikan, tipe enum, atau pengidentifikasi lain yang sesuai)
| mailing_id (KEY) | user_type (UNIQUE1) | internal_id (UNIQUE2)|
------------------------------------------------------------------
| 1001 | MSG_ADMIN | 87 |
| 1002 | MSG_PROF | 123 |
| 1003 | MSG_STUDENT | 123 |
Dengan pengaturan ini, dan indeks komposit unik dari {user_type, internal_id} segalanya menjadi jauh lebih bersih, 3NF dipertahankan, dan kode aplikasi tidak harus memeriksa untuk anomali I / U.
Pada sisi negatifnya, ada sedikit kehilangan transparansi dalam menentukan tabel sumber pengguna yang harus ditangani di luar DB, pada dasarnya berjumlah pemetaan tingkat aplikasi nilai-nilai user_type ke tabel. Saat ini, saya (agak kuat) condong ke arah pemetaan ke-2 ini, karena downside agak kecil.
TETAPI saya dengan susah payah menyadari keterbatasan saya sendiri, dan saya yakin saya mungkin telah melewatkan keuntungan atau batu sandungan di kedua arah, jadi saya beralih ke pikiran yang lebih bijaksana daripada milik saya.