Dalam dunia database, ada beberapa hal yang disepakati secara universal. Peningkatan RAM sebagian besar bermanfaat untuk sistem DMBS. Menyebarkan data dan file log pada RAID meningkatkan kinerja.
Konvensi penamaan bukanlah salah satunya.
Ini adalah topik polarisasi yang mengejutkan, dengan para pendukung berbagai metodologi mengakar kuat di posisi mereka. Dan sangat vokal dan bersemangat dalam membela hal yang sama.
Artikel ini akan menyelidiki beberapa konvensi khusus dan argumen di kedua sisi, sambil mencoba menyajikan kesimpulan yang masuk akal untuk setiap poin.
Debat Pluralisasi Hebat
Pada intinya, ini adalah topik yang sederhana. Misalnya, apa cara yang benar untuk memberi nama tabel yang berisi informasi pelanggan dalam skema database relasional? Apakah itu Customer atau Customer ?
Argumen di kedua sisi berlimpah.
Sekilas , wajar untuk memikirkan kumpulan objek dalam bentuk jamak. Sekelompok beberapa individu atau perusahaan akan menjadi Pelanggan . Oleh karena itu, sebuah tabel (menjadi kumpulan objek) harus diberi nama dalam bentuk jamak. Satu baris dalam tabel itu akan menjadi satu pelanggan .
Prinsip penamaan ISO/IEC, meskipun bertanggal, merekomendasikan nama tabel jamak dan nama kolom tunggal.
Sebagian besar tabel sistem SQL Server menggunakan nama jamak (sysnotifications , sysoperator ), tetapi ini tidak konsisten. Mengapa sysproxylogin dan bukan sysproxylogins ?
Dalam argumen untuk nama tabel jamak, baris dalam tabel juga dirujuk sebagai 'instance' dari keseluruhan - mirip dengan item dalam koleksi. Pelanggan mendefinisikan seluruh rangkaian; satu pelanggan adalah turunan dari Pelanggan .
Sebaliknya, ada banyak alasan untuk menggunakan nama objek tunggal.
Meskipun mungkin ada banyak item (atau pelanggan ) dalam sebuah tabel, tabel itu sendiri dapat dianggap sebagai satu kesatuan. kotak pelanggan bukanlah "kotak pelanggan", bahkan jika memiliki banyak pelanggan di dalamnya. Selain itu, mungkin hanya ada satu item – atau tidak sama sekali – di dalam tabel, membuat “pelanggan” menjadi keliru.
Jika Anda memilih untuk mengubah nama tabel berdasarkan varian kata, inkonsistensi dapat dengan cepat muncul. Sementara banyak kata akan langsung (Pelanggan menjadi Pelanggan , Produk menjadi Produk ), kata lain mungkin tidak. Dalam hal ini, Orang bisa menjadi Orang atau Orang; satu Moose akan terlihat sama dengan bentuk jamaknya, Moose . (Meskipun mengapa Anda membutuhkan meja rusa?) Sebuah konvensi seperti People.FirstName mulai menjadi membingungkan dan tidak jelas.
Jika banyak bahasa terlibat, situasinya menjadi lebih buruk. Karena pluralisasi kata dapat bervariasi dalam banyak hal (pelanggan, tikus, rusa besar, anak-anak, krisis, silabus, pesawat), penutur non-pribumi memiliki tantangan tambahan. Tetap menggunakan nama objek tunggal akan menghindari masalah ini sepenuhnya.
Pertanyaan Konvensi Kasus
Tidak ada semangat yang sama dengan konvensi kasus seperti dengan pluralisasi, tetapi argumen dibuat untuk beberapa opsi berbeda. Mereka termasuk:
- Kasus Pascal :Huruf pertama dari setiap kata yang digabungkan menggunakan huruf besar, seperti pada:
CustomerOrder -
Kasus Unta :Huruf pertama dari kata pertama adalah huruf kecil; semua kata gabungan berikutnya memiliki huruf pertama yang dikapitalisasi, seperti pada:
customerOrderPascal Case terkadang dianggap sebagai subtipe dari Camel Case, tetapi Microsoft umumnya membedakan keduanya.
Untuk kata yang kurang dari tiga karakter, disarankan untuk menggunakan huruf besar saja, seperti pada
UIatauIO. - Garis bawahi [Kasus “C”] :Kata-kata dipisahkan dengan garis bawah, seperti pada
Customer_Order, ataucustomer_Order– lebih banyak keputusan!
Para peneliti di Universitas Johns Hopkins melakukan studi tentang efisiensi penggunaan garis bawah dalam pemrograman nama objek. Mereka menemukan bahwa penggunaan Camel Case (atau Pascal Case) meningkatkan akurasi dan pengenalan pengetikan. Garis bawah banyak digunakan dalam pemrograman C, tetapi trennya mengarah ke Kasus Camel/Pascal dengan penekanan baru-baru ini pada bahasa gaya Microsoft dan Java.
Seperti topik lainnya, mengikuti konvensi yang mapan lebih penting daripada seleksi dari konvensi itu sendiri.
Pertimbangan tambahan di sini adalah sensitivitas huruf besar-kecil dari database. Pemeriksaan SQL Server menentukan sensitivitas ini dengan 'CS' (peka huruf besar/kecil) atau 'CI' (peka huruf besar/kecil) dalam nama pemeriksaan. Misalnya:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Dalam susunan peka huruf besar/kecil, Select * from myTable akan gagal terhadap objek MyTable . Ini mungkin membuat garis bawah sedikit lebih disukai untuk mencegah kebingungan, tetapi Intellisense juga membantu menghilangkan kesalahan pengetikan di sebagian besar lingkungan pemrograman modern.
Pertimbangan Konvensi Penamaan Lainnya
Debat Singular vs. Plural dan Great Case Question mungkin merupakan pertarungan yang paling sengit, tetapi setidaknya ada tiga area lagi yang perlu diingat ketika mempertimbangkan konvensi penamaan.
Hindari penggunaan kata-kata yang dicadangkan SQL Server sebagai nama objek. Ini termasuk tabel dan kolom. Misalnya – Pengguna , Waktu , dan Tanggal dicadangkan. Kata kunci yang dicadangkan mungkin memerlukan perawatan tambahan untuk referensi (seperti menggunakan tanda kurung siku) tergantung pada aplikasi pemanggil. Ini juga berlaku untuk spasi. Spasi dalam nama objek memerlukan tanda kutip untuk referensi.
Ini juga terkait dengan rekomendasi lain – presisi. System.CreateDate jauh lebih jelas daripada System.Date . Model yang dirancang dengan baik memungkinkan pemirsa untuk segera memahami tujuan dari objek yang mendasarinya. Ketika pengenal apa pun dirujuk sebagai kunci asing, jadilah nama yang bebas – Customer.CustomerID daripada Customer.ID .
Hindari awalan dan akhiran untuk tabel dan tampilan , seperti tblTable . Notasi Hongaria (yang selalu dimaksudkan untuk mengidentifikasi penggunaan variabel) dimasukkan ke dalam konvensi penamaan SQL Server yang umum, tetapi secara luas diejek. Pengidentifikasi objek harus menjelaskan apa yang terkandung di dalamnya, bukan objek itu sendiri.
Namun, awalan berguna dalam objek pendukung SQL Server , karena mereka menggambarkan sifat fungsional objek.
Berikut ini adalah prefiks yang diterima secara umum untuk objek SQL Server:
- IX:Indeks
- PK:Kunci Utama
- FK:Kunci Asing
- CK:Periksa Batasan
- DF:Bawaan
- UQ terkadang juga digunakan untuk indeks unik.
Model ini menggambarkan poin-poin yang didefinisikan di atas. Ini tidak memerlukan penjelasan tentang sifat data; konvensi penamaan tunggal digunakan, dan pengenal yang jelas tersedia.
Pada akhirnya, ada kelebihan dan kekurangan masing-masing pihak dalam konvensi penamaan debat. Namun, ada satu poin kunci yang dapat disepakati oleh kedua belah pihak:terlepas dari keputusan yang dibuat, tetaplah konsisten dengan konvensi yang dipilih.
Konvensi penamaan SQL apa yang Anda gunakan dan mengapa?
