Good DB Design: MyEdition

Pada kesempatan ini, saya ingin berbagi pengalaman tentang desain-mendesain basis data, berbasis pada pengalaman mengerjakan beberapa proyek pengembangan perangkat lunak yang pernah saya kerjakan. Ada beberapa hal yang biasanya menjadi perhatian saya khususnya masalah penamaan (naming convention), antara lain:

1. Penamaan entitas/tabel
   
   • Saya biasa menggunakan model penamaan full-lowercase pada nama entitas, dengan menambahkan underscore ( _ ) sebagai pemisah suku kata, jika lebih dari satu suku kata. Misal: Untuk sebuah entitas dengan nama "Periode Akademik", akan saya ubah menjadi periode_akademik ketika saya desain dalam bentuk diagram ER maupun ketika sudah saya implementasikan ke basis data relasional semacam MySQL, Oracle, atau SQL Server. Hal tersebut saya lakukan karena terkadang ada beberapa RDBMS yang akan mengubah secara otomatis case dari nama tabel yang dulunya sering saya namai dengan menggunakan model penamaan camelCase (periodeAkademik) menjadi full-lowercase, sehingga yang awalnya periodeAkademik akan menjadi periodeakademik yang secara kasat mata akan tampak agak susah untuk dibaca.
   • Selain itu, tabel hasil relasi dua entitas atau lebih yang seringkali merupakan hasil pembangkitan otomatis dari perangkat lunak CAD untuk desain basis data biasanya akan saya ubah juga secara manual agar kelihatan lebih well-defined dan tentu saja mudah dibaca, sesuai konsep, dkk.
2. Penamaan atribut/field/kolom
• Untuk penamaan atribut, saya tetap menggunakan model penamaan camelCase, karena kasus yang terjadi pada penamaan entitas sebelumnya tidak terjadi pada saat penamaan atribut ini. Mengapa camelCase yang saya gunakan? Saya menggunakan camelCase sebagai standar penamaan yang saya gunakan pada tiap nama yang saya buat karena selain cukup singkat (dibandingkan dengan penambahan underscore [ _ ]) juga agar dapat mengikuti standar kode program yang saya buat yang biasanya juga menggunakan standar penulisan nama dengan model camelCase. Misal: Ada himpunan atribut {"ID Pegawai", "Nama Pegawai", "Alamat Pegawai"} akan saya ubah ke bentuk {pegawaiId, pegawaiNama, pegawaiAlamat} atau sekedar {id, nama, alamat} jika memang identifier tabel tidak perlu dimasukkan sebagai nama atribut.
• Untuk penamaan atribut yang menjadi FK (foreign key) maka akan saya tulis identifier tabel referensinya selain nama atributnya sendiri, misalkan jika awalnya id pada tabel user, maka akan menjadi userId pada tabel transaksi atau sesuai konsep yang kita inginkan, misal penjualId yang pada intinya tetap mengacu ke atribut id pada tabel user.

Demikian, semoga ada manfaatnya. Barangkali Anda juga ingin berbagi pengalaman? Just put your comments here... :)