Dilema Penamaan Tabel: Nama Singular vs. Plural [ditutup]


1466

Academia mengatakan bahwa nama tabel harus merupakan singular dari entitas tempat mereka menyimpan atribut.

Saya tidak menyukai T-SQL yang membutuhkan tanda kurung siku di sekitar nama, tapi saya telah mengganti nama Userstabel menjadi singular, selamanya menghukum mereka yang menggunakan tabel untuk kadang-kadang harus menggunakan tanda kurung.

Perasaan usus saya adalah bahwa lebih tepat untuk tetap dengan bentuk tunggal, tetapi perasaan usus saya juga menunjukkan bahwa tanda kurung tidak diinginkan seperti nama kolom dengan spasi di dalamnya dll.

Haruskah saya tinggal, atau haruskah saya pergi?


Dup penamaan tabel Database sebelumnya , jamak atau tunggal , tetapi yang ini mendapat perhatian lebih.
outis

7
Saya terkejut bahwa lebih banyak orang tidak mengatakan: itu ditentukan oleh apa yang diwakili oleh satu baris. Dalam satu basis data, saya mungkin memiliki tabel yang barisnya mewakili satu widget, dan satu lagi yang hubungannya satu-ke-banyak dengan tabel itu berarti baris mewakili banyak widget. Tidak melakukan ini kehilangan ekspresif.
andygavin

1
Saya hanya ingin menambahkan itu dalam semua diskusi ini, harap dicatat bahwa sebuah tabel sama sekali bukan bentuk atau bentuk yang sama dengan kelas. Tabel adalah kumpulan elemen dari tipe tertentu yang dapat diurutkan, ditanya, dll. Pada properti individu. Kelas adalah kerangka kerja untuk menggambarkan properti dan perilaku dari tipe tertentu. Dalam istilah pengkodean OO, representasi tertutup ke tabel adalah kumpulan objek (tidak peduli ORM apa yang Anda gunakan). Sejauh ini, ini adalah jawaban google peringkat tertinggi untuk subjek ini, jadi meskipun pertanyaannya sudah ditutup, halaman tersebut masih memiliki nilai.

1
Saya akan menggunakan praktik umum ekosistem tempat Anda bekerja. Misalnya: Di Node.js ORMs seperti Bookshelf.js atau Objection.js terutama didasarkan pada "Knex.js". Dan dalam dokumentasi "Knex.js" Anda akan menemukan nama tabel dalam bentuk jamak. Jadi saya akan menggunakan jamak dalam domain itu. Sumber: knexjs.org/#Schema-createTable
Benny Neugebauer

2
Ya saya setuju. Masuk akal untuk memiliki tabel pengguna dan menyebutnya "AppUser" pada saat yang sama juga masuk akal untuk memiliki tabel aturan yang berlaku untuk jenis pengguna tertentu dan menyebutnya "UserRules"
Arindam

Jawaban:


242

Yang lain telah memberikan jawaban yang cukup bagus sejauh "standar" berjalan, tetapi saya hanya ingin menambahkan ini ... Apakah mungkin "Pengguna" (atau "Pengguna") sebenarnya bukan deskripsi lengkap dari data yang disimpan dalam tabel ? Bukannya Anda harus menjadi terlalu gila dengan nama tabel dan spesifisitas, tetapi mungkin sesuatu seperti "Widget_Users" (di mana "Widget" adalah nama aplikasi atau situs web Anda) akan lebih tepat.


7
Saya setuju. OrgUsers, AppUsers, apa pun untuk menghindari menggunakan kata kunci.
MikeW

7
-1. Pengguna Tabel (dan Negara, Bahasa) dapat digunakan dalam beberapa aplikasi secara bersamaan.
OZ_

129
Bukankah mengaitkan nama skema akan menghapus semua kebingungan? AppName1.Users, AppName2.Users?
Zo Memiliki

7
Saya tidak setuju dengan awalan tabel - yang mungkin harus berupa skema? - tapi saya setuju dengan "nama yang lebih deskriptif". Bahkan sesuatu yang sesederhana "AppUser" sudah cukup, tanpa memasuki seluruh perdebatan namespace.

7
Jawaban yang diterima ini lebih merupakan komentar sampingan dan tidak menjawab pertanyaan.
Viliami

1825

Saya memiliki pertanyaan yang sama, dan setelah membaca semua jawaban di sini saya pasti tetap dengan SINGULAR, alasan:

Alasan 1 (Konsep). Anda bisa memikirkan tas berisi apel seperti "AppleBag", tidak masalah jika mengandung 0, 1 atau jutaan apel, selalu tas yang sama. Tabel hanya itu, wadah, nama tabel harus menggambarkan apa yang dikandungnya, bukan berapa banyak data yang dikandungnya. Selain itu, konsep jamak lebih tentang bahasa yang diucapkan (sebenarnya untuk menentukan apakah ada satu atau lebih).

Alasan 2 . (Kenyamanan). lebih mudah keluar dengan nama tunggal, daripada dengan yang jamak. Objek dapat memiliki bentuk jamak tidak beraturan atau tidak jamak sama sekali, tetapi akan selalu memiliki bentuk jamak tunggal (dengan beberapa pengecualian seperti Berita).

  • Pelanggan
  • Memesan
  • Pengguna
  • Status
  • Berita

Alasan 3 . (Estetika dan Ketertiban). Khususnya dalam skenario master-detail, ini berbunyi lebih baik, menyelaraskan lebih baik dengan nama, dan memiliki urutan lebih logis (Master terlebih dahulu, Detail kedua):

  • 1. Pesanan
  • 2.OrderDetail

Dibandingkan dengan:

  • 1.EderDetails
  • 2. Pesanan

Alasan 4 (Kesederhanaan). Secara keseluruhan, Nama Tabel, Kunci Utama, Hubungan, Kelas Entitas ... lebih baik untuk menyadari hanya satu nama (tunggal) daripada dua (kelas tunggal, tabel jamak, bidang tunggal, rincian-tunggal master jamak ..) .)

  • Customer
  • Customer.CustomerID
  • CustomerAddress
  • public Class Customer {...}
  • SELECT FROM Customer WHERE CustomerID = 100

Setelah Anda tahu bahwa Anda berurusan dengan "Pelanggan", Anda dapat yakin bahwa Anda akan menggunakan kata yang sama untuk semua kebutuhan interaksi basis data Anda.

Alasan 5 . (Globalisasi). Dunia semakin kecil, Anda mungkin memiliki tim dari berbagai negara, tidak semua orang memiliki bahasa Inggris sebagai bahasa ibu. Akan lebih mudah bagi seorang programmer bahasa Inggris non-pribumi untuk memikirkan "Repositori" daripada "Repositori", atau "Status" daripada "Statuses". Memiliki nama tunggal dapat menyebabkan lebih sedikit kesalahan yang disebabkan oleh kesalahan pengetikan, menghemat waktu dengan tidak harus berpikir "apakah ini Anak atau Anak?", Maka meningkatkan produktivitas.

Alasan 6 . (Kenapa tidak?). Bahkan dapat menghemat waktu menulis, menghemat ruang disk, dan bahkan membuat keyboard komputer Anda lebih lama!

  • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
  • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Anda telah menyimpan 3 huruf, 3 byte, 3 hit keyboard ekstra :)

Dan akhirnya, Anda dapat memberi nama orang-orang yang mengacaukan nama-nama yang dipesan seperti:

  • Pengguna> LoginUser, AppUser, SystemUser, CMSUser, ...

Atau gunakan kurung persegi yang terkenal [Pengguna]


625
Saya berani bertaruh jika Anda meletakkan label di laci kaus kaki Anda akan menyebutnya "Socks".
Chris Ward

73
Pasti. Sulit untuk mendapatkan satu standar yang berfungsi untuk semua dan untuk semua orang, yang penting adalah yang bekerja untuk Anda. Ini bekerja untuk saya, dan di sini saya telah menjelaskan mengapa, tetapi sekali lagi, itu untuk saya, dan saya merasa sangat nyaman.
Nestor

451
Pertanyaan terbesar Chris, mengapa Anda mengikuti konvensi penamaan basis data ketika menamai laci kaus kaki?
Kyle Clegg

83
Jawaban ini membutuhkan lebih banyak pujian. Ini membahas banyak alasan praktis yang saya terapkan pada mengapa saya lebih suka nama tunggal. Diskusi alternatif tentang bahasa yang tepat dalam referensi set hanya filosofis dan mengaburkan poin sebenarnya. Singular bekerja lebih baik.
Jason

298
Saya punya laci "Sock" di rumah, bukan laci "Socks". Jika itu adalah database, saya akan menyebutnya tabel "Sock".
jlembke

260

Jika Anda menggunakan alat Pemetaan Objek Relasional atau akan di masa depan saya sarankan Singular .

Beberapa alat seperti LLBLGen dapat secara otomatis memperbaiki nama jamak seperti Pengguna ke Pengguna tanpa mengubah nama tabel itu sendiri. Mengapa ini penting? Karena ketika dipetakan Anda ingin terlihat seperti User.Name, bukan Users.Name atau lebih buruk dari beberapa tabel database lama saya penamaan tblUsers.strName yang hanya membingungkan dalam kode.

Aturan praktis saya yang baru adalah menilai bagaimana tampilannya setelah diubah menjadi objek.

satu tabel yang saya temukan yang tidak sesuai dengan penamaan baru yang saya gunakan adalah UsersInRoles. Tetapi akan selalu ada beberapa pengecualian dan bahkan dalam kasus ini terlihat baik sebagai UsersInRoles.Username.


48
Saya menolak dan saya akan memberitahu Anda mengapa, karena saya tidak setuju. ORM pada dasarnya adalah tentang pemetaan. Setiap alat ORM yang pernah saya gunakan mendukung menentukan nama tabel yang akan digunakan untuk entitas ketika berbeda dari nama entitas. Ini penting karena seluruh alasan kami memetakan ke basis data relasional adalah agar kami dapat dengan mudah membuat permintaan dan laporan ad-hoc dengan bentuk yang berbeda dari model objek kami. Kalau tidak, kita semua hanya akan menggunakan database objek / dokumen sekarang.
joshperry

25
ORM tidak boleh mendikte nama objek yang dipetakannya. Titik ORM adalah abstraksi objek, memberikan fleksibilitas ini.
barrypicker

19
Di dunia saya, saya mencoba menggunakan nama yang konsisten di seluruh proyek untuk menghindari membuang waktu bertanya-tanya apakah contoh ini memiliki huruf s pada akhirnya atau tidak. Fakta bahwa ORM dapat mengubah nama dan menjadi independen tidak berarti melakukan itu membantu sesama pengembang Anda.
John Nicholas

2
Beberapa ORM (seperti banyak alat pemrograman) memiliki perilaku default yang menghasilkan implementasi tanpa konfigurasi ... dengan titik penjualan PRODUCTIVITY. Jadi membuat kelas Karyawan, tanpa pemetaan eksplisit, akan menghasilkan tabel Karyawan secara default
user919426

1
@barrypicker. Nama jamak tidak hanya terlihat bodoh dalam kode ORM. Bentuk jamak terlihat buruk dalam SQL juga, terutama ketika merujuk ke atribut unik. Siapa yang tidak pernah menulis pilih user.id dari pengguna? Atau mungkin ... dari pengguna yang tersisa bergabung di thingy.user_id = user.id ...?
Samuel Danielson

219

Saya lebih suka menggunakan kata benda yang tidak terinfleksi , yang dalam bahasa Inggris adalah singular.

Mempengaruhi jumlah nama tabel menyebabkan masalah ortografis (seperti yang ditunjukkan oleh banyak jawaban lain), tetapi memilih untuk melakukannya karena tabel biasanya berisi banyak baris juga secara semantik penuh lubang. Ini lebih jelas jika kita mempertimbangkan bahasa yang menggunakan kata benda berdasarkan kasus (seperti yang dilakukan kebanyakan orang):

Karena kita biasanya melakukan sesuatu dengan baris, mengapa tidak memasukkan nama dalam kasus accusative? Jika kita memiliki tabel yang kita tulis lebih dari yang kita baca, mengapa tidak menuliskan namanya dalam datif? Ini meja dari sesuatu, mengapa tidak menggunakan genitive-nya? Kami tidak akan melakukan ini, karena tabel didefinisikan sebagai wadah abstrak yang ada terlepas dari keadaan atau penggunaannya. Memengaruhi kata benda tanpa alasan semantik yang pasti dan mutlak mengoceh.

Menggunakan kata benda yang tidak terinstal adalah hal yang sederhana, logis, teratur dan tidak tergantung bahasa.


37
Mungkin argumen paling logis tentang hal ini yang pernah saya lihat, dan membuat saya senang saya menghabiskan waktu itu dalam bahasa Latin. +1 pasti.

52
Yah saya jelas perlu meningkatkan kosakata saya.
TJ Biddle

19
+1 Lihat, ini adalah jenis jawaban yang dibutuhkan Internet lebih banyak. Bukti sempurna menggunakan kosakata yang kaya untuk mengeksekusi logika sempurna.
OCDev

8
Saya akan mencatat ini waktu berikutnya saya pemrograman dalam bahasa Latin. Sementara itu pengguna akan masuk ke tabel pengguna dan pelanggan ke tabel pelanggan.
Caltor 3-15

8
Yakin - tidak terkena itu. Menarik untuk melihat bahwa setelah sekian lama, pilihan populer "tunggal" dan "jamak" sama - sama salah!
Stuart

126

Konvensi apa yang mengharuskan tabel memiliki nama tunggal? Saya selalu berpikir itu adalah nama jamak.

Seorang pengguna ditambahkan ke tabel Pengguna.

Situs ini setuju:
http://vyaskn.tripod.com/object_naming.htm#Tables

Situs ini tidak setuju (tapi saya tidak setuju dengan itu):
http://justinsomnia.org/writings/naming_conventions.html


Seperti yang disebutkan orang lain: ini hanya pedoman. Pilih satu konvensi yang cocok untuk Anda dan perusahaan / proyek Anda dan tetap menggunakannya. Beralih antara kata tunggal dan jamak atau kadang-kadang menyingkat dan kadang-kadang tidak jauh lebih menjengkelkan.


46
Saat menerapkan teori himpunan ke tabel, setiap instance dalam himpunan tersebut merupakan himpunan himpunan, sehingga Apple adalah himpunan Apple, itu merupakan agnostik dari berapa banyak apel dalam himpunan - itu adalah Apple dengan banyak contoh. 'Kantung' apel tidak menjadi 'kantung' bila mengandung banyak apel.
LABA

89
Bagaimana jika Anda memiliki tas dengan 5 buah apel di dalamnya? Apakah Anda menyebutnya sekantong apel? atau sekantong apel?
Christopher Mahan

26
Saya pikir teorinya adalah bahwa himpunan itu bernama Apel. Satu apel masih "satu set Apel" - meskipun, satu set dengan satu contoh. Beberapa apel juga merupakan "seperangkat Apel".
Mark Brackett

26
@Christopher, jika raison d'être dari tas adalah untuk memegang apel dan hanya apel, maka itu adalah "tas apel", terlepas dari apakah itu mengandung 1 apel, 100 apel atau tidak ada apel.
Ian Mackinnon

14
@ Ian: Itu karena meja itu generik, dan dapat dibandingkan dengan wadah pengiriman (dapat berisi hampir apa saja, dari peti apel hingga peti sepeda motor Harley Davidson). Anda mengatakan: sebuah wadah kargo jeruk, bukan wadah kargo oranye. Anda mengatakan: wadah muatan suku cadang mobil, bukan wadah muatan suku cadang mobil. Jika Anda membuat struktur data khusus yang dimaksudkan hanya untuk menyimpan jenis data tertentu, seperti nama apel, dan Anda menamainya "kungabogo", maka Anda dapat memiliki apel kungaboko. Saya tahu apa yang Anda pikirkan, tetapi pikirkan dulu kantung bola, dan pahami perbedaan artinya.
Christopher Mahan

79

Bagaimana ini sebagai contoh sederhana:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL di yang terakhir lebih aneh dari yang sebelumnya.

Saya memilih singular .


50
Dalam contoh itu, ya, tetapi dalam sql praktis itu tidak akan pernah ditulis seperti itu. Anda akan memiliki alias tabel sehingga akan lebih sepertiSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'
Michael Haren

+1, (setahun kemudian) Anda mengutip contoh TERRIFIC tentang bagaimana singular masuk akal. Ini agak perdebatan agama. Saya beralih ke singular beberapa tahun yang lalu oleh seorang arsitek data bertahun-tahun senior saya dan itu terasa benar bagi saya (setelah membutuhkan banyak meyakinkan bagi saya untuk beralih).
Chris Adragna

24
Saya pikir sql terdengar lebih jamak. Anda tidak akan memiliki nama tabel untuk setiap kolom, mengapa Anda suka mengetik begitu banyak. SELECT Name, Address FROM Customers WHERE Name> "def" Anda memilih dari kumpulan pelanggan yang namanya lebih besar daripada def.
Jamiegs

6
Bagaimana kalau menggunakan alias / AS untuk mengatasi satu masalah itu? SELECT Customer.Name, Customer.Address DARI Pelanggan AS Pelanggan MANA Customer.Name> "def"
James Hughes

1
Yang kedua terdengar jauh lebih baik, suara tunggal seperti seseorang yang tidak bisa berbahasa Inggris.
HLGEM

61

Saya sangat yakin bahwa dalam Diagram Relasi Entitas, entitas harus direfleksikan dengan nama tunggal, mirip dengan nama kelas yang singular. Setelah instantiated, namanya mencerminkan instance-nya. Jadi dengan database, entitas ketika dibuat menjadi tabel (kumpulan entitas atau catatan) adalah jamak. Entitas, Pengguna dibuat menjadi tabel Pengguna. Saya setuju dengan orang lain yang menyarankan mungkin nama Pengguna dapat ditingkatkan menjadi Karyawan atau sesuatu yang lebih berlaku untuk skenario Anda.

Ini kemudian lebih masuk akal dalam pernyataan SQL karena Anda memilih dari sekelompok catatan dan jika nama tabel tunggal, itu tidak terbaca dengan baik.


3
Saya terutama menyukai komentar pernyataan SQL. Menggunakan singular di sini tidak terasa intuitif bagi pembaca.
hochl

2
Poin bagus tentang ERD. Saya menduga inilah sebabnya, bagi seseorang yang melihat dunia melalui mata DBA, penamaan tunggal masuk akal. Saya menduga mereka tidak mendapatkan, seperti yang Anda tunjukkan, perbedaan antara entitas dan koleksi mereka.
William T. Mallard

1
Tabel bukanlah kumpulan catatan; sebuah tabel adalah definisi dari apa yang tampak seperti catatan. Itulah yang tampaknya dimiliki oleh semua orang majemuk / tunggal.
kaya remer

Saya tidak setuju dengan komentar pernyataan SQL. Bagaimana jika Anda ingin bergabung melawan Users.Id
hashtable

1
Satu old_lady memiliki banyak kucing ATAU old_ladies memiliki kucing. Saya pikir ERD dibaca lebih baik sebagai jamak. Dan tabel entitas, tabel memiliki banyak entitas sehingga sekali lagi saya pikir jamak terdengar bagus.
user3121518

39

Saya tetap dengan singular untuk nama tabel dan entitas pemrograman apa pun.

Alasannya? Fakta bahwa ada bentuk jamak tidak teratur dalam bahasa Inggris seperti tikus, tikus, dan domba . Lalu, jika saya membutuhkan koleksi , saya hanya menggunakan mouse atau domba , dan melanjutkan.

Ini benar-benar membantu pluralitas menonjol, dan saya dapat dengan mudah dan terprogram menentukan seperti apa koleksi benda itu.

Jadi, aturan saya adalah: semuanya singular, setiap koleksi hal adalah singular dengan s ditambahkan. Membantu dengan ORM juga.


7
bagaimana dengan kata yang diakhiri dengan 's'? Jika Anda memiliki tabel yang disebut 'Berita' (hanya sebagai contoh), apa yang Anda sebut kumpulan berita? Berita? Atau Anda akan memanggil meja 'Baru'?
Anthony

18
Saya akan memanggil tabel NewsItem dan koleksi NewsItems.
Ash Machine

5
Bagaimana jika Anda harus memeriksa ejaan semua kode atau yang lain itu tidak akan dikompilasi;)?
Hamish Grubijan

2
ORM tidak boleh mendikte nama objek yang dipetakannya. Titik ORM adalah abstraksi objek, memberikan fleksibilitas ini.
barrypicker

16
@HamishGrubijan kemudian berhenti menggunakan Word untuk menulis kode Anda! ;)
Valentino Vranken

37

IMHO, nama tabel harus jamak seperti Pelanggan .

Nama kelas harus tunggal seperti Pelanggan jika memetakan ke baris dalam tabel Pelanggan .


33

Tunggal. Saya tidak membeli argumen yang melibatkan mana yang paling logis - setiap orang berpikir preferensi sendiri paling logis. Apa pun yang Anda lakukan itu berantakan, pilih saja sebuah kebaktian dan patuhi itu. Kami mencoba memetakan bahasa dengan tata bahasa dan semantik yang sangat tidak teratur (bahasa lisan dan tulisan yang normal) ke tata bahasa yang sangat teratur (SQL) dengan semantik yang sangat spesifik.

Argumen utama saya adalah bahwa saya tidak menganggap tabel sebagai himpunan tetapi sebagai hubungan.

Jadi, AppUserrelasi memberitahu entitas mana AppUsers.

The AppUserGrouphubungan memberitahu saya yang entitas yangAppUserGroups

The AppUser_AppUserGroupkaitannya memberitahu saya bagaimana AppUsersdan AppUserGroupsterkait.

The AppUserGroup_AppUserGroupkaitannya memberitahu saya bagaimana AppUserGroupsdan AppUserGroupsterkait (kelompok yaitu anggota kelompok).

Dengan kata lain, ketika saya berpikir tentang entitas dan bagaimana mereka terkait, saya memikirkan hubungan dalam bentuk tunggal, tetapi tentu saja, ketika saya memikirkan entitas dalam koleksi atau set, koleksi atau set adalah jamak.

Dalam kode saya, kemudian, dan dalam skema database, saya menggunakan singular. Dalam deskripsi tekstual, saya akhirnya menggunakan jamak untuk meningkatkan keterbacaan - kemudian menggunakan font dll untuk membedakan tabel / nama relasi dari jamak s.

Saya suka menganggapnya berantakan, tetapi sistematis - dan dengan cara ini selalu ada nama yang dihasilkan secara sistematis untuk hubungan yang ingin saya ungkapkan, yang bagi saya sangat penting.


1
persis. hal utama yang banyak orang tidak sadari di sini adalah apa yang mereka namakan ... Anda memberi nama pada suatu relasi (satu catatan dalam tabel), bukan kumpulan rekaman dalam tabel.
Alexandre Martini

3
Tidak bisa tidak setuju lagi. 'Pilih * dari Pengguna dengan Nama seperti' J% '' karena saya memilih semua pengguna yang namanya dimulai dengan 'J'. Jika argumen Anda adalah bahwa Anda ingin menulis '... di mana User.Name like ...' maka cukup gunakan alias. Alasan yang sama saya katakan 'Beri saya sepasang dari semua kaus kaki yang tersedia.'
Mark A. Donohoe

Jika saya begitu khusus nama tabel saya akan sock_pair
Manuel Hernandez

@AlexandreMartini Tepat. Seperti beberapa orang yang menyebut satu catatan di tabel "relasi".
Nuno André

31

Saya juga akan menggunakan bentuk jamak , dan dengan dilema Pengguna yang disebutkan di atas , kami menggunakan pendekatan tanda kurung siku.

Kami melakukan ini untuk memberikan keseragaman antara arsitektur basis data dan arsitektur aplikasi, dengan pemahaman yang mendasari bahwa tabel Users adalah kumpulan nilai-nilai Pengguna sebanyak koleksi Users dalam artifact kode adalah kumpulan objek Pengguna .

Memiliki tim data kami dan pengembang kami berbicara bahasa konseptual yang sama (meskipun tidak selalu nama objek yang sama) membuatnya lebih mudah untuk menyampaikan ide di antara mereka.


8
Saya setuju .. mengapa ada ketidakkonsistenan antara kode dan penyimpanan? Saya tidak akan pernah menyebut koleksi objek pengguna "Pengguna" dalam kode ... jadi mengapa saya akan memanggil tabel itu? Itu tidak masuk akal. Ketika saya membaca argumen di atas tentang hal itu, mereka berfokus pada entitas, bukan tabel ... ada perbedaan antara apa yang ada di tabel daripada tabel itu sendiri dalam pikiran saya.
Jason

Bagaimana Anda menangani nama tabel seperti di companiesmana tabel lain memiliki bidang referensi yang disebut company_id? Meskipun dieja dengan benar, tampaknya tidak konsisten bagi mereka yang pilih-pilih tentang konvensi penamaan tabel.
Jake Wilson

1
Dengan mengingat bahwa singular of companiesadalah company, dan id ini adalah referensi ke item singular. Seharusnya tidak mengganggu kita dalam kode seperti itu mengganggu kita dalam bahasa Inggris.
David

22

Saya pribadi lebih suka menggunakan nama jamak untuk mewakili satu set, itu hanya "terdengar" lebih baik untuk pikiran relasional saya.

Pada saat yang tepat ini saya menggunakan nama tunggal untuk menentukan model data untuk perusahaan saya, karena sebagian besar orang di tempat kerja merasa lebih nyaman dengan itu. Kadang-kadang Anda hanya perlu membuat hidup lebih mudah untuk semua orang daripada memaksakan preferensi pribadi Anda. (begitulah saya berakhir di utas ini, untuk mendapatkan konfirmasi tentang apa yang seharusnya menjadi "praktik terbaik" untuk tabel penamaan)

Setelah membaca semua argumen di utas ini, saya mencapai satu kesimpulan:

Saya suka pancake saya dengan madu, tidak peduli apa rasa favorit semua orang. Tetapi jika saya memasak untuk orang lain, saya akan mencoba menyajikan sesuatu yang mereka sukai.


Tidak bijaksana untuk menggunakan konvensi semacam itu di dunia model relasional, terutama ketika Anda menggambarkan hubungan antara objek, misalnya "Setiap Tim mungkin hanya memiliki satu Pelatih Utama dan banyak Pelatih sekunder", yang dijelaskan: Tim-> MainCoach, Tim - >> SecondaryCoach
noonex

16

Tunggal. Saya akan memanggil array yang berisi sekelompok objek representasi baris pengguna 'pengguna', tetapi tabelnya adalah 'tabel pengguna'. Memikirkan tabel sebagai apa-apa selain kumpulan baris yang dikandungnya salah, IMO; tabel adalah metadata, dan himpunan baris secara hierarkis melekat pada tabel, itu bukan tabel itu sendiri.

Saya menggunakan ORM sepanjang waktu, tentu saja, dan ini membantu bahwa kode ORM yang ditulis dengan nama tabel jamak terlihat bodoh.


Untuk masing-masing miliknya, kurasa. Tabel database relasional secara definisi merupakan heading (yaitu metadata yang menamai atribut) dan satu set tuple yang cocok dengan heading. Anda dapat fokus pada metadata, sedangkan orang lain fokus pada tupel. :-)
Bill Karwin

Hai, User_Table adalah nama yang saya suka! :)
Camilo Martin

3
ORM tidak boleh mendikte nama objek yang dipetakannya. Titik ORM adalah abstraksi objek, memberikan fleksibilitas ini.
barrypicker

1
Saya melihatnya dengan cara ini .. jika Anda membuat array / daftar / kamus apa pun dalam kode, taruhan saya adalah nama Anda dengan nama jamak dari apa pun yang dimilikinya. Jika Anda menggunakan ORM untuk abstrak database Anda, tabel diwakili dengan semacam koleksi, jadi mengapa Anda akan memperlakukannya berbeda? Untuk menggunakan nama tunggal mungkin terdengar bagus, tetapi Anda selalu melawan insting Anda bahwa sebuah tabel memiliki banyak hal yang sama, seperti halnya kumpulan kode. Mengapa tidak konsisten?
Jason

@ Jason: Silakan membandingkan dan kontras cara hal-hal ini baca: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).
chaos

16

Sebenarnya saya selalu berpikir itu adalah konvensi populer untuk menggunakan nama tabel jamak. Sampai saat ini saya selalu menggunakan jamak.

Saya bisa memahami argumen untuk nama tabel tunggal, tetapi bagi saya jamak lebih masuk akal. Nama tabel biasanya menggambarkan isi tabel tersebut. Dalam database yang dinormalisasi, setiap tabel berisi set data tertentu. Setiap baris adalah entitas dan tabel berisi banyak entitas. Jadi bentuk jamak untuk nama tabel.

Tabel mobil akan memiliki nama mobil dan setiap baris adalah mobil. Saya akan mengakui bahwa menentukan tabel bersama dengan bidang dengan table.fieldcara adalah praktik terbaik dan bahwa memiliki nama tabel tunggal lebih mudah dibaca. Namun dalam dua contoh berikut, yang pertama lebih masuk akal:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

Jujur, saya akan memikirkan kembali posisi saya mengenai masalah ini, dan saya akan bergantung pada konvensi yang sebenarnya digunakan oleh organisasi yang saya kembangkan. Namun, saya pikir untuk konvensi pribadi saya, saya akan tetap menggunakan nama tabel jamak. Bagi saya itu lebih masuk akal.


9
Bukankah ini juga konvensi dalam RoR? Nama jamak untuk tabel dan Singular untuk kelas ORM? Masuk akal bagi saya. Tabel disebut "mobil" karena memiliki banyak contoh "mobil" dan kelas disebut "Mobil" karena akan menampung satu contoh mobil !!
Sap

@Sap Koreksi kecil pada bagian akhir kalimat Anda - Kelas "Mobil" adalah Tipe Data Abstrak yang mewakili Mobil kehidupan nyata. Apakah itu akan menampung satu instance atau multipel tergantung pada bagaimana ia digunakan.
asgs

mari kita hadapi itu, tabel caradalah definisi dari struktur mobil tunggal. Jika Anda melihat struktur tabel, pada dasarnya ia akan meludahkan "id int, color string etc." selanjutnya: katakan Anda memiliki tabel car_vendor(atau untuk versi jamak Anda cars_vendor) dengan kunci asing cars_id?! omong kosong apa itu? itu car_id tidak perlu untuk membuat saya berpikir. Singular sangat disukai oleh saya
Toskan

4
Saya sangat suka jawaban ini! Biarkan saya jelaskan. Jika koleksinya adalah cardan Anda ingin semuanya dari caritu bluehasilnya harus seperti tire, mirror, engine. Dan kemudian semakin membingungkan karena semua hasil partsdari a car. Jadi nama tabelnya harus carparts(atau car_parts, CarPartsapa pun yang Anda suka)
arnoudhgz

Setiap perancang basis data yang memberlakukan nama tabel tunggal pada dasarnya menyatakan perang terhadap pengembang aplikasi Ruby on Rails yang mungkin berhubungan dengan basis data tersebut di masa depan. Desakan ketat Rail pada kata-kata tunggal untuk kelas, dan nama-nama yang jamak untuk tabel, memungkinkan banyak perilaku kuat dalam banyak permata di dalam ekosistem Ruby. Jadi, bahkan jika Anda berpikir suara tunggal lebih baik, demi kompatibilitas Anda harus tetap menggunakan jamak. Saya membayangkan ini berlaku untuk banyak Pemetaan Relasi Objek lainnya juga.
Kelsey Hannan

15

Saya tidak suka nama tabel jamak karena beberapa kata benda dalam bahasa Inggris tidak dapat dihitung (air, sup, uang tunai) atau artinya berubah ketika Anda membuatnya dapat dihitung (ayam vs ayam; daging vs burung). Saya juga tidak suka menggunakan singkatan untuk nama tabel atau nama kolom karena hal itu menambah kemiringan ekstra pada kurva pembelajaran yang sudah curam.

Ironisnya, saya mungkin membuat Userpengecualian dan menyebutnya Userskarena USER (Transac-SQL) , karena saya juga tidak suka menggunakan tanda kurung di sekitar tabel jika saya tidak perlu.

Saya juga suka memberi nama semua kolom ID sebagai Id, bukan ChickenIdatau ChickensId(apa yang orang jamak lakukan tentang ini?).

Semua ini karena saya tidak memiliki penghormatan yang tepat untuk sistem basis data, saya hanya menerapkan kembali pengetahuan satu trik-kuda dari konvensi penamaan OO seperti Java karena kebiasaan dan kemalasan. Saya berharap ada dukungan IDE yang lebih baik untuk SQL yang rumit.


8
Kami orang jamak baik nama kolom 'id' 'id' seperti yang Anda lakukan, atau 'singular_id'. Saya percaya tabel harus jamak (anggap saja seperti array), tetapi nama kolom harus singular (atribut elemen tunggal).
mpen

plu_ral / PluRal untuk nama tabel, singular_id / singularId untuk kunci primer.
hochl

14

Kami menjalankan standar yang serupa, ketika membuat skrip kami meminta [] di sekitar nama, dan jika kualifikasi skema yang sesuai - utamanya lindung nilai taruhan Anda terhadap perebutan nama masa depan oleh sintaks SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Ini telah menyelamatkan jiwa kita di masa lalu - beberapa sistem basis data kita telah berjalan 10+ tahun dari SQL 6.0 hingga SQL 2005 - melewati masa hidup yang dimaksudkan.


Sepertinya ritualisasi diri bersifat ritualistik. Apakah ada perebutan nama seperti itu terjadi?
Kjetil S.

13

Tabel: jamak

Beberapa pengguna tercantum dalam tabel pengguna.

Model: tunggal

Pengguna tunggal dapat dipilih dari tabel pengguna.

Pengendali: jamak

http://myapp.com/users akan mendaftar beberapa pengguna.

Lagipula itu adalah pendapat saya.


1
Lebih dekat dengan pendapat saya, tetapi milik saya adalah bahwa penyimpanan tabel beberapa pengguna sebenarnya insidental, dan bahwa setiap pengguna tunggal diwakili oleh tabel, atau lebih tepatnya hubungan yang merupakan kumpulan tupel yang mewakili entitas Pengguna.
ProfK

Saya pikir saya cenderung setuju dengan ini. Satu-satunya hal yang membingungkan saya adalah mengapa model harus tunggal? Hanya jika model hanya berkaitan dengan satu Pengguna. Jika saya meminta db untuk mendapatkan semua pengguna maka apakah saya perlu mengakses model? Tidak masuk akal untuk contoh tunggal untuk mengambil semua catatan, contoh: $ user-> get_all () // tidak masuk akal
PM7Temp

12

Saya seorang penggemar nama tabel tunggal karena mereka membuat diagram ER saya menggunakan sintaksis KASUS lebih mudah dibaca, tetapi dengan membaca tanggapan ini saya merasa tidak pernah tertangkap dengan baik? Saya pribadi menyukainya. Ada tinjauan umum yang baik dengan contoh-contoh bagaimana dapat dibaca model Anda ketika Anda menggunakan nama tabel tunggal, menambahkan kata kerja tindakan untuk hubungan Anda dan membentuk kalimat yang baik untuk setiap hubungan. Itu semua sedikit berlebihan untuk database 20 tabel tetapi jika Anda memiliki DB dengan ratusan tabel dan desain yang rumit bagaimana pengembang Anda akan memahaminya tanpa diagram yang dapat dibaca?

http://www.aisintl.com/case/method.html

Adapun awalan tabel dan tampilan saya benar-benar benci praktik itu. Berikan seseorang tidak ada informasi sama sekali sebelum memberi mereka informasi yang mungkin buruk. Siapa pun yang menelusuri db untuk objek dapat dengan mudah mengetahui tabel dari tampilan, tetapi jika saya memiliki tabel bernama tblUsers yang karena alasan tertentu saya memutuskan untuk merestrukturisasi di masa depan menjadi dua tabel, dengan tampilan menyatukan mereka agar tidak melanggar kode lama Saya sekarang memiliki pandangan bernama tblUsers. Pada titik ini saya dibiarkan dengan dua opsi yang tidak menarik, meninggalkan tampilan bernama dengan awalan tbl yang dapat membingungkan beberapa pengembang, atau memaksa lapisan lain, baik tingkat menengah atau aplikasi yang akan ditulis ulang untuk merujuk struktur baru saya atau menggunakan nama viewUsers. Itu meniadakan sebagian besar nilai pandangan IMHO.


1
Contoh bagus jebakan nama objek awalan dengan kualifikasi 'tipe'!
Kenny Evitt

12

Sistem tables/viewsdari server itu sendiri ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, dll) hampir selalu jamak. Saya kira demi konsistensi saya akan mengikuti jejak mereka.


Microsoft apa adanya karena alasan bisnis terlebih dahulu (dan seringkali alasan tidak etis pada saat itu), alasan logis bertahan. Satu-satunya alasan saya untuk mengikuti mereka adalah bahwa mereka adalah gorila besar dan semua orang seperti itu. Ketika saya punya pilihan, saya memilih cara lain.
Bruce Patin

1
Perlu dicatat bahwa information_schemaini adalah bagian dari ISO / IEC 9075-11, standar SQL. Dan ya, itu memang menggunakan nama tabel jamak / tampilan.
Paulo Freitas

10

Jika kita melihat MS SQL Server'stabel sistem, nama mereka yang ditentukan oleh Microsoft ada di plural.

Tabel sistem Oracle diberi nama singular. Meskipun beberapa di antaranya bersifat jamak. Oracle merekomendasikan jamak untuk nama tabel yang ditentukan pengguna. Itu tidak masuk akal bahwa mereka merekomendasikan satu hal dan mengikuti yang lain. Bahwa arsitek di dua raksasa perangkat lunak ini menamai meja mereka menggunakan konvensi yang berbeda, tidak masuk akal juga ... Lagipula, apa yang orang-orang ini ... PhD?

Saya ingat di dunia akademis, rekomendasinya singular.

Misalnya, ketika kita mengatakan:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

mungkin b / c masing ID- masing dipilih dari satu baris tertentu ...?


1
Microsoft apa adanya karena alasan bisnis terlebih dahulu (dan seringkali alasan tidak etis pada saat itu), alasan logis bertahan. Satu-satunya alasan saya untuk mengikuti mereka adalah bahwa mereka adalah gorila besar dan semua orang seperti itu. Ketika saya punya pilihan, saya memilih cara lain.
Bruce Patin

Dua hal. Pertama, Anda biasanya tidak akan menggunakan nama tabel dan akan menulis 'pilih ID DARI OrderHeaders WHERE Referensi =' ABC123 'karena Anda' Memilih semua ID dari OrderHeaders di mana ada sesuatu yang benar 'tetapi jika Anda harus menggunakan nama tabel karena suatu bergabung atau apa pun, Anda akan menggunakan alias seperti ... 'pilih OrderHeader.ID DARI OrderHeader sebagai OrderHeader WHERE OrderHeader.Reference =' ABC123 '
Mark A. Donohoe

9

Ini mungkin agak berlebihan, tetapi saya menyarankan agar berhati-hati. Tidak harus bahwa itu buruk untuk mengubah nama tabel, tetapi standardisasi hanya itu; sebuah standar - database ini mungkin sudah "distandarisasi", betapapun buruknya :) - Saya akan menyarankan konsistensi untuk menjadi tujuan yang lebih baik mengingat bahwa database ini sudah ada dan mungkin terdiri lebih dari hanya 2 tabel.

Kecuali jika Anda dapat membakukan seluruh database, atau setidaknya berencana untuk bekerja untuk tujuan itu, saya menduga bahwa nama tabel hanyalah puncak gunung es dan berkonsentrasi pada tugas yang ada, menahan rasa sakit dari benda-benda yang namanya buruk, mungkin ada di minat terbaik Anda -

Konsistensi praktis kadang-kadang adalah standar terbaik ... :)

my2cents ---


9

Alternatif yang mungkin:

  • Ganti nama tabel SystemUser
  • Gunakan tanda kurung
  • Simpan nama tabel jamak.

IMO menggunakan tanda kurung secara teknis pendekatan yang paling aman, meskipun agak rumit. IMO itu 6 dari satu, setengah lusin dari yang lain, dan solusi Anda benar-benar hanya bermuara pada preferensi pribadi / tim.


2
Saya suka ide 'awalan' Anda, tetapi akan menyebutnya SystemUser.
ProfK

9

Pandangan saya dalam semantik tergantung pada bagaimana Anda mendefinisikan wadah Anda. Misalnya, "kantong apel" atau "apel" atau "kantong apel" atau "apel".

Contoh: tabel "college" dapat berisi 0 perguruan tinggi atau lebih, sebuah tabel "college" dapat berisi 0 perguruan tinggi atau lebih

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Kesimpulan saya adalah baik-baik saja tetapi Anda harus mendefinisikan bagaimana Anda (atau orang-orang yang berinteraksi dengannya) akan mendekati ketika merujuk ke tabel; "tabel kapak" atau "tabel xs"


8

Seperti yang disebutkan orang lain di sini, konvensi harus menjadi alat untuk menambah kemudahan penggunaan dan keterbacaan. Bukan sebagai belenggu atau klub untuk menyiksa pengembang.

Yang mengatakan, preferensi pribadi saya adalah menggunakan nama tunggal untuk tabel dan kolom. Ini mungkin berasal dari latar belakang pemrograman saya. Nama-nama kelas umumnya tunggal kecuali mereka semacam koleksi. Dalam benak saya, saya menyimpan atau membaca catatan individual dalam tabel yang dimaksud, jadi singular masuk akal bagi saya.

Praktek ini juga memungkinkan saya untuk memesan nama tabel jamak bagi mereka yang menyimpan banyak-ke-banyak hubungan antara objek saya.

Saya mencoba untuk menghindari kata-kata yang dicadangkan di nama tabel dan kolom saya, juga. Dalam kasus yang dipermasalahkan di sini, lebih masuk akal untuk menentang konvensi tunggal bagi Pengguna untuk menghindari keharusan merangkum tabel yang menggunakan kata Pengguna yang dilindungi undang-undang.

Saya suka menggunakan awalan secara terbatas (tbl untuk nama tabel, sp_ untuk nama proc, dll), meskipun banyak yang percaya ini menambah kekacauan. Saya juga lebih suka nama CamelBack untuk menggarisbawahi karena saya selalu berakhir dengan memukul + bukannya _ saat mengetik nama. Banyak yang lain tidak setuju.

Berikut ini tautan lain yang bagus untuk penamaan pedoman konvensi: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Ingatlah bahwa faktor terpenting dalam konvensi Anda adalah masuk akal bagi orang-orang yang berinteraksi dengan database yang dimaksud. Tidak ada "Satu Cincin untuk Menguasai Mereka Semua" ketika datang ke konvensi penamaan.


18
Mengabaikan kengerian notasi hungaria. Tidak pernah, tidak pernah, tidak pernah menggunakan sp_ di depan prosedur yang tersimpan karena MS-SQL menggunakannya untuk prosedur yang disimpan sistem dan memperlakukannya khusus. Karena sp_ disimpan dalam tabel master, MS-SQL selalu terlihat lebih dulu bahkan jika Anda memenuhi syarat lokasi.
Will Dieterich

8

Saya pikir menggunakan bentuk tunggal adalah apa yang kami pelajari di universitas. Tetapi pada saat yang sama Anda bisa berpendapat bahwa tidak seperti dalam pemrograman berorientasi objek, tabel bukan merupakan instance dari catatannya.

Saya pikir saya memberi tip dalam mendukung singular pada saat ini karena penyimpangan jamak dalam bahasa Inggris. Di Jerman bahkan lebih buruk karena tidak ada bentuk jamak yang konsisten - kadang-kadang Anda tidak dapat mengatakan apakah suatu kata jamak atau tidak tanpa artikel yang menentukan di depannya (der / die / das). Dan dalam bahasa Cina toh tidak ada bentuk jamak.


Di universitas saya diajar jamak untuk tabel, saya juga punya buku di sini, manajemen DB edisi ketiga dari 90-an, tabel tunggal; sementara saya juga memiliki salinan yang diperbarui, 11e, tunggal dan beberapa nama yang disingkat, sedangkan bagian XML menggunakan jamak. \ n Tetapi jika Anda memeriksa konten yang sebenarnya untuk bagian RDBMS, itu benar-benar masih teks yang sama dengan beberapa gambar mendapatkan face lift. \ "The checklist pemodelan data" tidak menyatakan apa-apa pada jamak vs tunggal, hanya bahwa entitas hanya harus memetakan ke objek tunggal, itu mungkin apa yang mereka coba untuk menegakkan dalam buku.
Marco

8

Saya pernah menggunakan "Bung" untuk tabel Pengguna - jumlah karakter yang sama, tidak ada konflik dengan kata kunci, masih referensi ke manusia biasa. Jika saya tidak khawatir tentang kepala pengap yang mungkin melihat kode, saya akan tetap seperti itu.


8

Saya selalu menggunakan singular hanya karena itulah yang diajarkan kepada saya. Namun, saat membuat skema baru baru-baru ini, untuk pertama kalinya dalam waktu yang lama, saya secara aktif memutuskan untuk mempertahankan konvensi ini hanya karena ... lebih pendek. Menambahkan 's' di akhir setiap nama tabel sepertinya tidak berguna bagi saya seperti menambahkan 'tbl_' di depan setiap nama tabel.


7

Saya selalu berpikir itu adalah kebodohan. Saya menggunakan nama tabel jamak.

(Saya percaya rasional di balik kebijakan itu adalah bahwa hal itu membuat lebih mudah bagi generator kode ORM untuk menghasilkan kelas objek & koleksi, karena lebih mudah untuk menghasilkan nama jamak dari nama tunggal daripada sebaliknya)


11
Konvensi ini telah menjadi bagian dari teori relasional jauh, lama, sebelum ORM pernah ada.
LABA

1
ORM tidak boleh mendikte nama objek yang dipetakannya. Titik ORM adalah abstraksi objek, memberikan fleksibilitas ini.
barrypicker

7

Saya hanya menggunakan kata benda untuk nama tabel saya yang dieja sama, apakah tunggal atau jamak:

rusa rusa ikan pesawat Anda celana celana pendek gunting spesies keturunan


6

Saya tidak melihat ini diartikulasikan dengan jelas dalam jawaban sebelumnya. Banyak programmer tidak memiliki definisi formal dalam pikiran ketika bekerja dengan tabel. Kita sering berkomunikasi secara intuitif dalam hal "catatan" atau "baris". Namun, dengan beberapa pengecualian untuk hubungan yang didenormalisasi, tabel biasanya dirancang sedemikian rupa sehingga hubungan antara atribut non-kunci dan kunci merupakan fungsi teoritis set.

Fungsi dapat didefinisikan sebagai subset dari produk silang antara dua set, di mana setiap elemen set kunci paling banyak muncul sekali dalam pemetaan. Oleh karena itu terminologi yang muncul dari perspektif itu cenderung tunggal. Seseorang melihat konvensi tunggal (atau setidaknya, non-jamak) yang sama di seluruh teori matematika dan komputasi lain yang melibatkan fungsi (misalnya aljabar dan lambda kalkulus).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.