Setiap kali saya mendesain database, saya selalu bertanya-tanya apakah ada cara terbaik untuk memberi nama suatu item dalam database saya. Cukup sering saya bertanya pada diri sendiri pertanyaan-pertanyaan berikut:
- Haruskah nama tabel jamak?
- Haruskah nama kolom tunggal?
- Haruskah saya awali tabel atau kolom?
- Haruskah saya menggunakan kasing apa pun dalam penamaan item?
Apakah ada pedoman yang direkomendasikan di luar sana untuk penamaan item dalam database?
Jawaban:
Saya sarankan memeriksa database sampel SQL Server Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
Sampel AdventureWorks menggunakan konvensi penamaan yang sangat jelas dan konsisten yang menggunakan nama skema untuk organisasi objek database.
sumber
Jawaban terlambat di sini, tetapi singkatnya:
Elaborasi:
(1) Apa yang harus Anda lakukan. Ada sangat sedikit hal yang harus Anda lakukan dengan cara tertentu, setiap saat, tetapi ada beberapa.
(2) Apa yang harus Anda lakukan.
(3) Apa yang harus Anda pertimbangkan.
sumber
CustomerID
kunci utama dariCustomer
tabel, atau kunci asing di beberapa tabel lainnya. Ini masalah kecil. Mengapa Anda ingin menggunakan nama yang burukc
?CustomerID = Customer.ID
sangat jelas karena Anda melihat bahwa Anda bergabung dengan kunci asing dengan kunci utama; itu tidak berlebihan karena kedua belah pihak adalah dua hal yang berbeda. Penamaan karakter tunggal adalah praktik IMO yang buruk.Oke, karena kita mempertimbangkan pendapat:
Saya percaya bahwa nama tabel harus jamak. Tabel adalah kumpulan (tabel) entitas. Setiap baris mewakili satu entitas, dan tabel mewakili koleksi. Jadi saya akan memanggil meja entitas Orang Orang (atau Orang, apa pun yang Anda suka).
Bagi mereka yang suka melihat "nama entitas" tunggal dalam kueri, itulah yang akan saya gunakan untuk alias tabel:
Sedikit seperti LINQ "dari orang di orang pilih orang. Nama".
Sedangkan untuk 2, 3 dan 4, saya setuju dengan @Lars.
sumber
Saya bekerja di tim pendukung basis data dengan tiga DBA dan opsi yang dipertimbangkan adalah:
Kami menggunakan nama tunggal untuk tabel. Tabel cenderung diawali dengan nama sistem (atau akronimnya). Ini berguna jika sistem menjadi kompleks karena Anda dapat mengubah awalan untuk mengelompokkan tabel bersama secara logis (mis. Reg_customer, reg_booking, dan regadmin_limits).
Untuk bidang, kami berharap nama bidang akan menyertakan awalan / akryonm dari tabel (yaitu cust_address1) dan kami juga lebih suka menggunakan seperangkat sufiks standar (_id untuk PK, _cd untuk "kode", "nama" untuk "kode", "nama" untuk "nama" ", _nb untuk" number ", _dt untuk" Date ").
Nama bidang kunci Foriegn harus sama dengan bidang kunci Utama.
yaitu
Saat mengembangkan proyek baru, saya sarankan Anda menuliskan semua nama entitas, awalan, dan akronim yang disukai dan memberikan dokumen ini kepada pengembang Anda. Kemudian, ketika mereka memutuskan untuk membuat tabel baru, mereka bisa merujuk ke dokumen daripada "menebak" apa tabel dan bidang yang harus dipanggil.
sumber
Baik. Itu $ 0,02 saya
sumber
Saya juga mendukung konvensi penamaan gaya ISO / IEC 11179, mencatat bahwa itu adalah pedoman dan bukan preskriptif.
Lihat Nama elemen data di Wikipedia :
"Tabel adalah Koleksi Entitas, dan ikuti panduan penamaan Koleksi. Idealnya, nama kolektif digunakan: mis., Personel. Jamak juga benar: Karyawan. Nama yang salah termasuk: Karyawan, tblEmployee, dan EmployeeTable."
Seperti biasa, ada pengecualian untuk aturan misalnya tabel yang selalu memiliki tepat satu baris mungkin lebih baik dengan nama tunggal misalnya tabel konfigurasi. Dan konsistensi adalah yang paling penting: periksa apakah Anda berbelanja memiliki konvensi dan, jika demikian, ikuti; jika Anda tidak suka maka lakukan bisnis untuk mengubahnya daripada menjadi ranger sendirian.
sumber
Saya mendengar argumen sepanjang waktu bahwa apakah meja itu jamak atau tidak adalah semua masalah selera pribadi dan tidak ada praktik terbaik. Saya tidak percaya itu benar, terutama sebagai programmer yang bertentangan dengan DBA. Sejauh yang saya ketahui, tidak ada alasan yang sah untuk menjamur nama tabel selain "Itu masuk akal bagi saya karena itu adalah kumpulan objek," sementara ada keuntungan yang sah dalam kode dengan memiliki nama tabel tunggal. Sebagai contoh:
Ini menghindari bug dan kesalahan yang disebabkan oleh ambiguitas jamak. Pemrogram tidak benar-benar dikenal karena keahlian mengeja mereka, dan mengucur beberapa kata membingungkan. Sebagai contoh, apakah kata jamak berakhir dengan 'es' atau just 's'? Apakah itu orang atau orang? Saat Anda mengerjakan proyek dengan tim besar, ini bisa menjadi masalah. Misalnya, contoh di mana anggota tim menggunakan metode yang tidak benar untuk menjernihkan tabel yang ia buat. Pada saat saya berinteraksi dengan tabel ini, digunakan di seluruh kode saya tidak memiliki akses ke atau akan terlalu lama untuk memperbaikinya. Hasilnya adalah saya harus ingat untuk mengeja tabel yang salah setiap kali saya menggunakannya. Sesuatu yang sangat mirip dengan ini terjadi pada saya. Semakin mudah Anda membuat setiap anggota tim untuk secara konsisten dan mudah menggunakan yang tepat, memperbaiki nama tabel tanpa kesalahan atau harus mencari nama tabel sepanjang waktu, semakin baik. Versi tunggal lebih mudah untuk ditangani dalam lingkungan tim.
Jika Anda menggunakan versi tunggal nama tabel DAN awalan kunci utama dengan nama tabel, Anda sekarang memiliki keuntungan dengan mudah menentukan nama tabel dari kunci utama atau sebaliknya melalui kode saja. Anda dapat diberi variabel dengan nama tabel di dalamnya, menyatukan "Id" sampai akhir, dan sekarang Anda memiliki kunci utama tabel melalui kode, tanpa harus melakukan kueri tambahan. Atau Anda dapat memotong "Id" dari ujung kunci utama untuk menentukan nama tabel melalui kode. Jika Anda menggunakan "id" tanpa nama tabel untuk kunci utama, maka Anda tidak dapat melalui kode menentukan nama tabel dari kunci primer. Selain itu, kebanyakan orang yang menjamur nama tabel dan awalan kolom PK dengan nama tabel menggunakan versi tunggal dari nama tabel di PK (misalnya status dan status_id),
Jika Anda membuat nama tabel tunggal, Anda dapat membuatnya cocok dengan nama kelas yang diwakilinya. Sekali lagi, ini dapat menyederhanakan kode dan memungkinkan Anda untuk melakukan hal-hal yang benar-benar rapi, seperti membuat instance kelas dengan tidak memiliki apa-apa selain nama tabel. Itu juga hanya membuat kode Anda lebih konsisten, yang mengarah ke ...
Jika Anda membuat nama tabel tunggal, itu membuat skema penamaan Anda konsisten, terorganisir, dan mudah dipelihara di setiap lokasi. Anda tahu bahwa dalam setiap contoh dalam kode Anda, apakah itu dalam nama kolom, sebagai nama kelas, atau sebagai nama tabel, itu adalah nama persis yang sama. Ini memungkinkan Anda melakukan pencarian global untuk melihat di mana-mana data digunakan. Saat Anda menjernihkan nama tabel, akan ada kasus di mana Anda akan menggunakan versi tunggal dari nama tabel itu (kelas yang berubah menjadi, di kunci utama). Masuk akal untuk tidak memiliki beberapa contoh di mana data Anda disebut sebagai jamak dan beberapa contoh tunggal.
Singkatnya, jika Anda menjernihkan nama tabel Anda, Anda kehilangan segala macam keuntungan dalam membuat kode Anda lebih pintar dan lebih mudah ditangani. Bahkan mungkin ada kasus di mana Anda harus memiliki tabel pencarian / array untuk mengkonversi nama tabel Anda menjadi objek atau nama kode lokal yang bisa Anda hindari. Nama meja tunggal, meskipun mungkin merasa sedikit aneh pada awalnya, menawarkan keuntungan signifikan dibandingkan nama jamak dan saya percaya ini adalah praktik terbaik.
sumber
preferensi kami:
Haruskah nama tabel jamak?
Tidak pernah. Argumen untuk itu sebagai koleksi masuk akal, tetapi Anda tidak pernah tahu tabel apa yang akan berisi (0,1 atau banyak item). Aturan jamak membuat penamaan tidak perlu rumit. 1 Rumah, 2 rumah, mouse vs tikus, orang vs orang, dan kami bahkan belum melihat bahasa lain.
Update person set property = 'value'
bertindak pada setiap orang dalam tabel.Select * from person where person.name = 'Greg'
mengembalikan koleksi / rowset baris orang.Haruskah nama kolom tunggal?
Biasanya, ya, kecuali di mana Anda melanggar aturan normalisasi.
Haruskah saya awali tabel atau kolom?
Sebagian besar preferensi platform. Kami lebih suka awalan kolom dengan nama tabel. Kami tidak membuat awalan tabel, tetapi kami melakukan tampilan awalan (v_) dan prosedur tersimpan_ (sp_ atau f_ (fungsi)). Itu membantu orang-orang yang ingin mencoba upday v_person.age yang sebenarnya merupakan bidang terhitung dalam tampilan (yang tidak bisa di-UPDATEd juga).
Ini juga cara yang bagus untuk menghindari tabrakan kata kunci (delivery.from jeda, tetapi delivery_from tidak).
Itu membuat kode lebih verbose, tetapi sering membantu keterbacaan.
bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
... sangat mudah dibaca dan eksplisit. Ini bisa lepas kendali:
customer.customer_customer_type_id
menunjukkan hubungan antara pelanggan dan tabel customer_type, menunjukkan kunci utama pada tabel customer_type (customer_type_id) dan jika Anda pernah melihat 'customer_customer_type_id' saat men-debug permintaan, Anda langsung tahu dari mana asalnya (tabel pelanggan).
atau di mana Anda memiliki hubungan MM antara customer_type dan customer_category (hanya tipe tertentu yang tersedia untuk kategori tertentu)
customer_category_customer_type_id
... sedikit (!) di sisi panjang.
Haruskah saya menggunakan kasing apa pun dalam penamaan item? Ya - huruf kecil :), dengan garis bawah. Ini sangat mudah dibaca dan lintas platform. Bersama dengan 3 di atas juga masuk akal.
Sebagian besar dari ini adalah preferensi. - Selama Anda konsisten, itu harus dapat diprediksi bagi siapa saja yang harus membacanya.
sumber
SELECT * FROM people AS person WHERE person.name = 'Greg'
terdengar paling alami bagi saya.<table name><id>
, misalnyaPersonID
atauPerson_ID
lain - lain. Oleh karena itu, lebih masuk akal jika Anda TIDAK menamai tabel Anda dalam bentuk jamak karena setiap catatan adalah orang yang terpisah bukan orang.Lihatlah ISO 11179-5: Penamaan dan prinsip identifikasi Anda bisa mendapatkannya di sini: http://metadata-standards.org/11179/#11179-5
Saya membuat blog tentang hal itu beberapa waktu lalu di sini: ISO-11179 Konvensi Penamaan
sumber
Saya tahu ini sudah terlambat, dan pertanyaan sudah dijawab dengan sangat baik, tetapi saya ingin memberikan pendapat saya tentang # 3 tentang awalan nama kolom.
Semua kolom harus dinamai dengan awalan yang unik untuk tabel tempat mereka didefinisikan.
Misalnya tabel yang diberikan "pelanggan" dan "alamat", mari kita pergi dengan awalan "cust" dan "addr", masing-masing. "pelanggan" akan memiliki "cust_id", "cust_name", dll. di dalamnya. "address" akan memiliki "addr_id", "addr_cust_id" (FK kembali ke pelanggan), "addr_street", dll. di dalamnya.
Ketika saya pertama kali disajikan dengan standar ini, saya sangat menentangnya; Saya benci ide itu. Saya tidak tahan dengan semua pengetikan dan redundansi ekstra itu. Sekarang saya sudah memiliki pengalaman yang cukup sehingga saya tidak akan pernah kembali.
Hasil dari melakukan ini adalah bahwa semua kolom dalam skema database Anda unik. Ada satu manfaat utama untuk ini, yang mengalahkan semua argumen yang menentangnya (menurut saya, tentu saja):
Anda dapat mencari seluruh basis kode dan andal menemukan setiap baris kode yang menyentuh kolom tertentu.
Manfaat dari # 1 sangat besar. Saya dapat mencela kolom dan tahu persis file apa yang perlu diperbarui sebelum kolom dapat dihapus dengan aman dari skema. Saya dapat mengubah arti kolom dan tahu persis kode apa yang perlu di refactored. Atau saya dapat dengan mudah mengetahui apakah data dari suatu kolom bahkan digunakan di bagian tertentu dari sistem. Saya tidak dapat menghitung berapa kali ini telah mengubah proyek yang berpotensi besar menjadi proyek yang sederhana, atau jumlah jam yang kami hemat dalam pekerjaan pengembangan.
Manfaat lain yang relatif kecil adalah Anda hanya perlu menggunakan alias-tabel ketika Anda bergabung sendiri:
sumber
reliably find every line of code that touches a particular column
... Bukankah itu intinya?Pendapat saya tentang ini adalah:
1) Tidak, nama tabel harus tunggal.
Meskipun tampaknya masuk akal untuk pemilihan sederhana (
select * from Orders
), kurang masuk akal untuk OO yang setara (Orders x = new Orders
).Tabel dalam DB benar-benar himpunan entitas itu, itu lebih masuk akal setelah Anda menggunakan set-logika:
Baris terakhir itu, logika aktual dari join, terlihat membingungkan dengan nama tabel jamak.
Saya tidak yakin tentang selalu menggunakan alias (seperti yang disarankan Matt) mengosongkannya.
2) Mereka harus tunggal karena mereka hanya memiliki 1 properti
3) Tidak pernah, jika nama kolom ambigu (seperti di atas di mana mereka berdua memiliki kolom yang disebut [Kunci]) nama tabel (atau aliasnya) dapat membedakan mereka dengan cukup baik. Anda ingin kueri diketik dengan cepat dan sederhana - awalan menambah kompleksitas yang tidak perlu.
4) Apa pun yang Anda inginkan, saya sarankan CapitalCase
Saya tidak berpikir ada satu set pedoman mutlak tentang semua ini.
Selama apapun yang Anda pilih konsisten di seluruh aplikasi atau DB, saya rasa itu tidak penting.
sumber
CapitalCase
?pascal case
Product.ProductName
,Product.ProductID
,Product.ProductPrice
dll mengetikProduct.P
memberi Anda semua bidang yang diawali.Menurutku:
Namun, seperti yang telah disebutkan, konvensi apa pun lebih baik daripada tidak ada konvensi. Tidak peduli bagaimana Anda memilih untuk melakukannya, dokumentasikan sehingga modifikasi di masa depan mengikuti konvensi yang sama.
sumber
Saya pikir jawaban terbaik untuk setiap pertanyaan itu akan diberikan oleh Anda dan tim Anda. Jauh lebih penting untuk memiliki konvensi penamaan lalu bagaimana konvensi penamaan sebenarnya.
Karena tidak ada jawaban yang tepat untuk itu, Anda harus meluangkan waktu (tetapi tidak terlalu banyak) dan memilih konvensi Anda sendiri dan - inilah bagian penting - patuhi itu.
Tentu saja baik untuk mencari beberapa informasi tentang standar tentang hal itu, yang merupakan apa yang Anda tanyakan, tetapi jangan cemas atau khawatir tentang jumlah jawaban berbeda yang mungkin Anda dapatkan: pilih salah satu yang tampaknya lebih baik untuk Anda.
Untuk jaga-jaga, inilah jawaban saya:
sumber
sumber
SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'
tabel jamak, kolom tunggal. Lagi-lagi selalu masalah pendapat pribadi.Konvensi penamaan memungkinkan tim pengembangan untuk merancang kemampuan menemukan dan mempertahankan di jantung proyek.
Konvensi penamaan yang baik membutuhkan waktu untuk berevolusi tetapi begitu sudah ada, memungkinkan tim untuk bergerak maju dengan bahasa yang sama. Konvensi penamaan yang baik tumbuh secara organik dengan proyek. Konvensi penamaan yang baik dengan mudah mengatasi perubahan selama fase terpanjang dan paling penting dari siklus hidup perangkat lunak - manajemen layanan dalam produksi.
Inilah jawaban saya:
Penamaan itu sulit, tetapi di setiap organisasi ada seseorang yang dapat menyebutkan nama dan di setiap tim perangkat lunak harus ada seseorang yang bertanggung jawab atas standar penamaan dan memastikan bahwa masalah penamaan seperti sec_id , sec_value , dan security_id diselesaikan lebih awal sebelum mereka dimasukkan ke dalam proyek .
Jadi apa prinsip dasar dari konvensi dan standar penamaan yang baik: -
sumber
Inilah tautan yang menawarkan beberapa pilihan. Saya sedang mencari spesifikasi sederhana yang bisa saya ikuti daripada harus bergantung pada spesifikasi yang ditentukan sebagian.
http://justinsomnia.org/writings/naming_conventions.html
sumber
sumber
Lastname
seharusnyaLastName
Nama tabel harus selalu tunggal, karena mereka mewakili satu set objek. Seperti yang Anda katakan kawanan untuk menunjuk sekelompok domba, atau kawanan memang menunjuk sekelompok burung. Tidak perlu jamak. Ketika nama tabel adalah komposisi dari dua nama dan konvensi penamaan dalam bentuk jamak, menjadi sulit untuk mengetahui apakah nama jamak harus menjadi kata pertama atau kata kedua atau keduanya. Logikanya - Object.instance, bukan object.instance. Atau TableName.column, bukan TableNames.column. Microsoft SQL tidak peka huruf besar-kecil, lebih mudah membaca nama tabel, jika huruf besar digunakan, untuk memisahkan nama tabel atau kolom ketika mereka terdiri dari dua atau lebih nama.
sumber
User
adalah tidak sekelompok pengguna.Nama Tabel: Ini harus singular, karena merupakan entitas tunggal yang mewakili objek dunia nyata dan bukan objek, yang singlular.
Nama Kolom: Seharusnya singular hanya setelah itu menyatakan bahwa itu akan memiliki nilai atom dan akan mengkonfirmasi teori normalisasi. Namun, jika ada n jumlah jenis properti yang sama, maka mereka harus diakhiri dengan 1, 2, ..., n, dll.
Prefixing Tabel / Kolom: Ini adalah topik besar, akan dibahas nanti.
Casing: Seharusnya case unta
Teman saya, Patrick Karcher , saya meminta Anda untuk tidak menulis apa pun yang mungkin menyinggung seseorang, seperti yang Anda tulis, "• Lebih lanjut, kunci asing harus disebutkan secara konsisten di tabel yang berbeda. Seharusnya legal untuk memukuli seseorang yang tidak melakukan hal ini.". Saya tidak pernah melakukan kesalahan ini, teman saya Patrick, tetapi saya menulis secara umum. Bagaimana jika mereka bersama-sama berencana untuk mengalahkanmu karena ini? :)
sumber
Sangat terlambat ke pesta tetapi saya masih ingin menambahkan dua sen tentang awalan kolom
Tampaknya ada dua argumen utama untuk menggunakan standar penamaan table_column (atau tableColumn) untuk kolom, keduanya berdasarkan pada fakta bahwa nama kolom itu sendiri akan unik di seluruh database Anda:
1) Anda tidak harus menentukan nama tabel dan / atau alias kolom dalam kueri Anda sepanjang waktu
2) Anda dapat dengan mudah mencari seluruh kode Anda untuk nama kolom
Saya pikir kedua argumen tersebut cacat. Solusi untuk kedua masalah tanpa menggunakan awalan mudah. Ini proposal saya:
Selalu gunakan nama tabel dalam SQL Anda. Misalnya, selalu gunakan table.column daripada kolom.
Ini jelas memecahkan 2) karena sekarang Anda hanya dapat mencari table.column daripada table_column.
Tapi saya bisa mendengar Anda berteriak, bagaimana cara mengatasi 1)? Persis tentang menghindari ini. Ya, memang, tapi solusinya sangat cacat. Mengapa? Nah, solusi awalan bermuara ke:
Untuk menghindari harus menentukan table.column ketika ada ambiguitas, Anda beri nama semua kolom Anda table_column!
Tetapi ini berarti Anda mulai sekarang SELALU harus menulis nama kolom setiap kali Anda menentukan kolom. Tetapi jika Anda harus melakukan itu, apa manfaatnya daripada selalu menulis table.column secara eksplisit? Tepat, tidak ada manfaatnya, jumlah karakter yang persis sama untuk diketik.
sunting: ya, saya sadar bahwa penamaan kolom dengan awalan memberlakukan penggunaan yang benar sedangkan pendekatan saya bergantung pada programmer
sumber
Konvensi Penamaan Basis Data Esensial (dan Gaya) (klik di sini untuk keterangan lebih lanjut)
nama tabel memilih nama pendek, tidak ambigu, menggunakan tidak lebih dari satu atau dua kata membedakan tabel dengan mudah memfasilitasi penamaan nama bidang yang unik serta mencari dan menghubungkan tabel memberikan tabel nama tunggal, tidak pernah jamak (pembaruan: saya masih setuju dengan alasan yang diberikan untuk konvensi ini, tetapi kebanyakan orang sangat suka nama tabel jamak, jadi saya sudah melunakkan pendirian saya) ... ikuti tautan di atas
sumber
e.g. PATIENTS would have a primary key called pa_patient_id_pk
!!Nama tabel tunggal. Katakanlah Anda memodelkan hubungan antara seseorang dan alamatnya. Misalnya, jika Anda membaca datamodel, Anda lebih suka 'setiap orang dapat hidup dengan 0,1 atau banyak alamat.' atau 'setiap orang dapat hidup di 0,1 atau banyak alamat.' Saya pikir itu lebih mudah untuk pluralise alamat, daripada harus mengubah kata kata orang sebagai pribadi. Plus kata benda kolektif sering kali terpisah dari versi singular.
sumber
Ini adalah konvensi yang diajarkan kepada saya, tetapi Anda harus beradaptasi dengan apa pun yang Anda gunakan menggunakan selang.
sumber