Apa itu arc eksklusif dalam database dan mengapa itu jahat?

Saya membaca kesalahan desain database paling umum yang dibuat oleh pengembang Q&A di stackoverflow. Pada jawaban pertama ada ungkapan tentang arc eksklusif:

Busur eksklusif adalah kesalahan umum di mana sebuah tabel dibuat dengan dua atau lebih kunci asing di mana satu dan hanya satu saja yang bisa non-nol. Kesalahan besar. Untuk satu hal, mempertahankan integritas data menjadi jauh lebih sulit. Setelah semua, bahkan dengan integritas referensial, tidak ada yang mencegah dua atau lebih kunci asing ini ditetapkan (terlepas dari kendala pemeriksaan kompleks).

Saya benar-benar tidak mengerti mengapa busur eksklusif itu jahat. Mungkin saya tidak mengerti dasar-dasarnya. Apakah ada penjelasan bagus tentang busur eksklusif?

database-design

— Ali Arda Orhan
sumber

Jawaban:

Sejauh yang saya pahami sejak lama, dalam busur eksklusif sebuah tabel berisi sejumlah kolom yang merupakan kunci asing ke tabel lain, tetapi hanya satu di antaranya yang dapat diset pada satu waktu (karena beberapa kendala logis pada domain tersebut) berikut dari dunia nyata). Karena aturan ini tidak dapat diberlakukan pada database, catatan yang rusak dapat dibuat di mana lebih dari satu kunci asing ini memiliki nilai.

Saya akan membuat contoh. Pertimbangkan aplikasi tempat perusahaan melacak truk yang digunakannya untuk mengirimkan barang. Sebuah truk hanya dapat berada di salah satu dari tiga tempat pada saat yang sama: bisa dengan karyawan, bisa di garasi parkir atau di toko pemeliharaan. Ini dapat dimodelkan dengan memiliki tabel truk dengan employeeId, parkingGarageId dan maintenanceShopId, merujuk tabel Employee, ParkingGarage, dan MaintenanceShop. Tidak ada cara untuk menegakkan aturan bahwa hanya satu dari bidang ini yang diisi pada tingkat basis data. Kode buruk atau seseorang dengan akses langsung ke database bisa memasukkan catatan yang memiliki dua atau tiga bidang yang diisi, yang berarti korupsi data dalam database.

— JDT
sumber

Tiga lokasi truk yang memungkinkan adalah subclass dari superclass, "lokasi truk". Ada banyak kasus di mana subclass saling eksklusif. Tantangannya menjadi bagaimana memodelkan kelas dan subclass dalam tabel relasional.

— Walter Mitty

Saya setuju bahwa ada kasus di mana menggunakan desain ini dibenarkan. Saya bisa, bagaimanapun, juga setuju dengan posting asli bahwa pola ini digunakan BANYAK lebih dari yang seharusnya. Ini memiliki beberapa kerugian yang sangat besar juga ...

— JDT

Tidak bisakah batasan pemeriksaan digunakan? Sebagai contoh

alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null))

. Saya tidak suka busur eksklusif tetapi mereka dapat diberlakukan dengan batasan cek. Tentu saja kendala FK juga harus ada.

— Tulains Córdova

Oleh karena itu "kendala pemeriksaan rumit" dari pos yang dikutip di atas. Anda mungkin dapat melakukan validasi yang sangat canggih dengan kendala pemeriksaan atau heck, bahkan pemicu, yang tidak membuatnya menjadi ide yang baik atau tanda desain yang baik. Bayangkan melakukan pemeriksaan kendala pada busur eksklusif dengan empat atau lima kolom ... Juga, saya cukup yakin bahwa tidak semua mesin basis data mendukung kendala LIHAT . MySQL secara eksplisit menyatakan dalam dokumen bahwa LIHAT klausa diuraikan, tetapi diabaikan ...

— JDT

Sumber ini merekomendasikan arc eksklusif. Pikiran?

— Alex Moore-Niemi

Tidak ada yang jahat tentang busur eksklusif. Cukup menegakkan aturan bisnis terkait menggunakan kendala pemeriksaan. Sebagian besar sistem manajemen basis data utama mendukung kendala pemeriksaan (Oracle, SQL Server, PostgreSQL). Jika Anda menggunakan alat pemodelan data maka ada kemungkinan besar alat Anda akan secara otomatis menghasilkan kode untuk mengimplementasikan batasan pemeriksaan.

— Gary B
sumber

-1

Busur eksklusif sangat berguna dalam desain konseptual atau logis. Itu tidak berarti bahwa Anda harus mengimplementasikannya. Dalam contoh sebelumnya, perancang dapat memutuskan untuk mengimplementasikan desain dengan tiga tabel. Satu untuk lokasi parkir, satu untuk karyawan dan satu untuk bengkel.

— Trevor Cummings
sumber