Saran saya tentang pemodelan data adalah:
- Anda harus memilih kolom opsional (nullable) daripada gabungan 1:1 secara umum . Masih ada contoh di mana 1:1 masuk akal, biasanya berkisar pada subtipe. Orang-orang cenderung lebih mudah tersinggung dalam hal kolom yang dapat dibatalkan daripada yang mereka lakukan tentang bergabung secara aneh;
- Jangan dijadikan model juga tidak langsung kecuali benar-benar dibenarkan (lebih lanjut tentang ini di bawah);
- Penggabungan yang disukai daripada agregasi. Hal ini dapat bervariasi sehingga perlu diuji. Lihat Oracle vs MySQL vs SQL Server:Agregasi vs Bergabung untuk contoh ini;
- Bergabung lebih baik daripada N+1 pilihan. Pemilihan N+1 adalah, misalnya, memilih pesanan dari tabel database dan kemudian mengeluarkan kueri terpisah untuk mendapatkan semua item baris untuk pesanan itu;
- Skalabilitas penggabungan biasanya hanya masalah ketika Anda melakukan pemilihan massal. Jika Anda memilih satu baris dan kemudian menggabungkannya ke beberapa hal, ini jarang menjadi masalah (tetapi terkadang demikian);
- Kunci asing harus selalu diindeks kecuali Anda berurusan dengan tabel kecil yang sepele;
Selengkapnya di Kesalahan Pengembangan Database yang Dibuat oleh AppDevelopers .
Sekarang untuk keterusterangan model, izinkan saya memberi Anda sebuah contoh. Katakanlah Anda sedang merancang sistem untuk otentikasi dan otorisasi pengguna. Solusi overengineered mungkin terlihat seperti ini:
- Alias (id, nama pengguna, user_id);
- Pengguna (id, ...);
- Email (id, user_id, alamat email);
- Masuk (id, user_id, ...)
- Peran Masuk (id, login_id, role_id);
- Peran (id, nama);
- Hak Istimewa Peran (id, role_id, privilege_id);
- Hak Istimewa (id, nama).
Jadi, Anda perlu 6 gabungan untuk mendapatkan dari nama pengguna yang dimasukkan ke hak istimewa yang sebenarnya. Tentu mungkin ada persyaratan aktual untuk ini tetapi lebih sering daripada tidak sistem semacam ini dimasukkan karena meremas-remas tangan oleh beberapa pengembang berpikir mereka mungkin suatu hari nanti membutuhkannya meskipun setiap pengguna hanya memiliki satu alias, pengguna untuk login adalah 1 :1 dan seterusnya. Solusi yang lebih sederhana adalah:
- Pengguna (id, nama pengguna, alamat email, jenis pengguna)
dan, yah, itu saja. Mungkin jika Anda memerlukan sistem peran yang kompleks tetapi juga sangat mungkin bahwa Anda tidak melakukannya dan jika Anda melakukannya, cukup mudah untuk memasukkannya (tipe pengguna menjadi kunci asing ke dalam tipe pengguna atau tabel peran) atau umumnya mudah untuk memetakan lama ke yang baru.
Ini adalah hal tentang kompleksitas:mudah ditambahkan dan sulit dihilangkan. Biasanya ini adalah kewaspadaan konstan terhadap kerumitan yang tidak diinginkan, yang sudah cukup buruk tanpa berjalan dan memperburuknya dengan menambahkan kerumitan yang tidak perlu.
