Konvensi Penamaan Basis Data, Tabel, dan Kolom? [Tutup]

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:

1. Haruskah nama tabel jamak?
2. Haruskah nama kolom tunggal?
3. Haruskah saya awali tabel atau kolom?
4. Haruskah saya menggunakan kasing apa pun dalam penamaan item?

Apakah ada pedoman yang direkomendasikan di luar sana untuk penamaan item dalam database?

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.

1. Nama tunggal untuk tabel
2. Nama tunggal untuk kolom
3. Nama skema untuk awalan tabel (Misalnya: SchemeName.TableName)
4. Casing pascal (alias unta atas)

Jawaban terlambat di sini, tetapi singkatnya:

1. Preferensi saya jamak
2. Iya
3. Tabel : * Biasanya * tidak ada awalan yang terbaik. Kolom : Tidak.
4. Baik tabel dan kolom: PascalCase.

Elaborasi:

(1) Apa yang harus Anda lakukan. Ada sangat sedikit hal yang harus Anda lakukan dengan cara tertentu, setiap saat, tetapi ada beberapa.

• Beri nama kunci utama Anda menggunakan format "[singularOfTableName] ID". Yaitu, apakah nama tabel Anda adalah Pelanggan atau Pelanggan , kunci utama adalah CustomerID .
• Lebih lanjut, kunci asing harus dinamai secara konsisten dalam tabel yang berbeda. Adalah legal untuk memukuli seseorang yang tidak melakukan ini. Saya akan menyampaikan bahwa sementara batasan kunci asing didefinisikan sering penting, penamaan kunci asing konsisten selalu penting
• Basis data Anda harus memiliki konvensi internal . Meskipun di bagian selanjutnya Anda akan melihat saya sangat fleksibel, dalam penamaan basis data harus sangat konsisten. Apakah meja Anda untuk pelanggan disebut Pelanggan atau Pelanggan kurang penting daripada Anda melakukannya dengan cara yang sama di seluruh database yang sama. Dan Anda dapat membalik koin untuk menentukan cara menggunakan garis bawah, tetapi Anda harus tetap menggunakannya dengan cara yang sama . Jika Anda tidak melakukan ini, Anda adalah orang jahat yang harus memiliki harga diri rendah.

(2) Apa yang harus Anda lakukan.

• Bidang yang mewakili jenis data yang sama pada tabel yang berbeda harus dinamai sama. Tidak memiliki Zip di satu meja dan ZipCode di meja lainnya.
• Untuk memisahkan kata dalam nama tabel atau kolom Anda, gunakan PascalCasing. Menggunakan camelCasing pada dasarnya tidak akan menjadi masalah, tetapi itu bukan konvensi dan itu akan terlihat lucu. Saya akan membahas garis bawah sebentar lagi. (Anda tidak boleh menggunakan ALLCAPS seperti di masa lalu. OBNOXIOUSTABLE.ANNOYING_COLUMN baik-baik saja di DB2 20 tahun lalu, tetapi tidak sekarang.)
• Jangan mempersingkat atau menyingkat kata-kata secara artifisial. Lebih baik nama panjang dan jelas daripada pendek dan membingungkan. Nama ultra-pendek adalah peninggalan dari zaman yang lebih gelap dan lebih ganas. Cus_AddRef. Apa-apaan itu? Referensi Penerima Kustodian? Pengembalian Uang Tambahan Pelanggan? Rujukan Alamat Khusus?

(3) Apa yang harus Anda pertimbangkan.

• Saya benar-benar berpikir Anda harus memiliki nama jamak untuk tabel; beberapa berpikir singular. Baca argumen di tempat lain. Namun nama kolom harus tunggal. Bahkan jika Anda menggunakan nama tabel jamak, tabel yang mewakili kombinasi tabel lain mungkin ada dalam bentuk tunggal. Misalnya, jika Anda memiliki tabel Promosi dan Item , tabel yang mewakili item yang menjadi bagian dari promosi bisa berupa Promotions_Items, tetapi itu juga bisa secara sah menjadi Promotion_Item yang saya pikir (mencerminkan hubungan satu-ke-banyak).
• Gunakan garis bawah secara konsisten dan untuk tujuan tertentu. Hanya nama-nama tabel umum harus cukup jelas dengan PascalCasing; Anda tidak perlu menggarisbawahi kata-kata yang terpisah. Simpan garis bawah baik (a) untuk menunjukkan tabel asosiatif atau (b) untuk awalan, yang akan saya bahas di bullet berikutnya.
• Awalan tidak baik atau buruk. Ini biasanya bukan yang terbaik. Dalam db pertama atau dua Anda, saya tidak akan menyarankan menggunakan awalan untuk pengelompokan tabel secara umum. Tabel pada akhirnya tidak sesuai dengan kategori Anda dengan mudah, dan itu sebenarnya dapat membuat lebih sulit untuk menemukan tabel. Dengan pengalaman, Anda dapat merencanakan dan menerapkan skema awalan yang lebih baik daripada merugikan. Saya pernah bekerja di db ketika tabel data dimulai dengan tbl , config tables dengan ctbl , view dengan vew , proc's sp , dan udf's fn, dan beberapa lainnya; itu cermat, diterapkan secara konsisten sehingga bekerja dengan baik. Satu-satunya waktu Anda MEMBUTUHKAN awalan adalah ketika Anda memiliki solusi yang benar-benar terpisah yang karena alasan tertentu berada di db yang sama; awalan mereka bisa sangat membantu dalam mengelompokkan tabel. Prefixing juga oke untuk situasi khusus, seperti untuk tabel sementara yang ingin Anda menonjol.
• Sangat jarang (jika pernah) Anda ingin awalan kolom.

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:

SELECT person.Name
FROM People person

Sedikit seperti LINQ "dari orang di orang pilih orang. Nama".

Sedangkan untuk 2, 3 dan 4, saya setuju dengan @Lars.

Saya bekerja di tim pendukung basis data dengan tiga DBA dan opsi yang dipertimbangkan adalah:

1. Standar penamaan apa pun lebih baik daripada tidak ada standar.
2. Tidak ada standar "satu benar", kita semua memiliki preferensi
3. Jika sudah ada standar, gunakan itu. Jangan membuat standar lain atau mengotori standar yang ada.

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

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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.

1. Tidak. Tabel harus dinamai berdasarkan entitas yang diwakilinya. Orang, bukan orang adalah bagaimana Anda merujuk siapa pun yang direpresentasikan oleh salah satu catatan.
2. Sekali lagi, hal yang sama. Kolom FirstName benar-benar tidak boleh disebut FirstNames. Itu semua tergantung pada apa yang ingin Anda wakili dengan kolom.
3. TIDAK.
4. Iya. Berikan kejelasan. Jika Anda perlu memiliki kolom seperti "Nama Depan", casing akan membuatnya lebih mudah dibaca.

Baik. Itu $ 0,02 saya

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.

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:

1. 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.

2. 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),

3. 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 ...

4. 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.

preferensi kami:

1. 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.

2. Haruskah nama kolom tunggal?
   Biasanya, ya, kecuali di mana Anda melanggar aturan normalisasi.

3. 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.

4. 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.

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

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:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

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:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

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.

Menurutku:

1. Nama tabel harus jamak.
2. Nama kolom harus tunggal.
3. Tidak.
4. Baik CamelCase (pilihan saya) atau underscore_separated untuk nama tabel dan nama kolom.

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.

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:

1. Iya. Tabel adalah sekelompok catatan , guru atau aktor , jadi ... jamak.
2. Iya.
3. Saya tidak menggunakannya.
4. Basis data yang saya gunakan lebih sering - Firebird - menjaga semuanya dalam huruf besar, jadi tidak masalah. Lagi pula, ketika saya pemrograman saya menulis nama-nama dengan cara yang lebih mudah dibaca, seperti rilisTahun .

1. Jelas menyimpan nama tabel tunggal, orang bukan orang
   2. Sama disini
   3. Tidak. Saya telah melihat beberapa awalan yang mengerikan, sejauh menyatakan apa yang dihadapi adalah tabel (tbl_) atau prosedur penyimpanan pengguna (usp_). Ini diikuti oleh nama database ... Jangan lakukan itu!
   4. Iya. Saya cenderung PascalCase semua nama tabel saya

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:

1. Ya, nama tabel harus jamak ketika merujuk pada serangkaian perdagangan , sekuritas , atau rekanan misalnya.
2. Iya.
3. Iya. Tabel SQL diawali dengan tb_, pandangan diawali dengan vw_, prosedur tersimpan diawali dengan usp_ dan pemicu diawali dengan tg_ diikuti oleh nama database.
4. Nama kolom harus huruf kecil dipisahkan dengan garis bawah.

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: -

• Gunakan bahasa klien Anda dan domain solusi Anda
• Bersikap deskriptif
• Bersikaplah konsisten
• Disambiguasi, refleksi, dan refactor
• Jangan gunakan singkatan kecuali jelas untuk semua orang
• Jangan gunakan kata kunci khusus SQL sebagai nama kolom

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

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

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.

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? :)

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

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

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.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Ini adalah konvensi yang diajarkan kepada saya, tetapi Anda harus beradaptasi dengan apa pun yang Anda gunakan menggunakan selang.

1. Jamak. Ini adalah kumpulan entitas.
2. Iya. Atribut adalah representasi properti singular dari suatu entitas.
3. Ya, nama tabel awalan memungkinkan penamaan yang mudah dilacak dari semua indeks kendala dan alias tabel.
4. Casing Pascal untuk nama tabel dan kolom, awalan + SEMUA cap untuk indeks dan batasan.