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


791

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?


7
Saya pikir kita harus memberi nama jamak untuk Tabel dan tunggal untuk kolom.
AZ_

7
Saya melihat tabel sebagai "penyimpanan" dengan banyak item, bukan "entitas" tunggal, jadi saya beri nama jamak. Ketika saya memetakan tabel menjadi objek, saya akan menamai objek tersebut singular. Ini hanya pendapat pribadi saya.
dpp

2
@Tryinko Menggunakan ID di semua tempat adalah LIVING NERAKA bagi siapa pun yang bergabung dengan beberapa tabel. Tidak ada cara yang mungkin bahwa sedikit keuntungan mengetahui ini adalah PK lebih besar daripada gangguan luar biasa dari pengulangan kembali kolom ID dang di setiap kueri berdarah berulang-ulang. Jika Anda ingin cara untuk menunjukkan PK dalam sebuah tabel, jadikan itu kolom pertama. Juga, menunjukkan FK dalam nama kolom ada di pikiran saya anti-pola yang benar-benar jahat.
ErikE

Jawaban:


315

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)

14
wilsonmar.com/sql_adventureworks.htm adalah analisis yang sangat baik dari skema AdventureWorks.
Daniel Trebbien

209
Saya tidak akan bergantung pada Microsoft untuk standar apa pun - jika Anda melihat database northwind Anda akan melihat mereka menggunakan Tabel Plural, Nama Kolom Singular, Awalan Skema untuk Tabel, Awalan Tabel untuk Kolom Kunci Utama, Awalan Kendala Kendala Hungaria-esque dan terburuk. dari semua SPASI "" untuk nama tabel multi-kata. Selain itu tabel sistem untuk SQLServer menggunakan bentuk jamak jadi sepertinya AdventureWorks adalah kambing hitam dalam kelompok ini.
Marcus Pope

63
Saya pikir masalah utama di sini adalah bahwa kerumunan nama tabel Singular tampaknya mempertimbangkan tabel sebagai entitas, bukan baris dalam tabel yang kerumunan Plural lakukan. Anda harus bertanya pada diri sendiri yang mana. Jika tabel hanya sebuah wadah baris, bukankah lebih logis menggunakan penamaan jamak? Anda tidak akan pernah menamai koleksi dalam kode singular, lalu mengapa Anda menamai tabel singular? Mengapa tidak konsisten? Saya mendengar semua argumen tentang bagaimana mereka menyortir dan menggunakannya dalam gabungan tetapi semua itu tampaknya argumen yang sangat tipis. Jika semuanya tergantung pada preferensi, saya akan pergi dengan konsistensi dan menjamur.
Jason

4
Juga pertimbangkan ke arah mana gelombang akan menuju. Sepertinya terjadi dalam arah nama tabel jamak terutama karena semua tabel sistem di SQL Server semua jamak, dan default untuk Kerangka Entitas adalah jamak di luar kotak. Jika itu sikap Microsoft, saya ingin pergi ke arah mana kita akan berada dalam 20 tahun. Bahkan konvensi basis data Oracle menyebutkan nama tabel jamak. Bayangkan berapa banyak pengembang c # yang membenci kata kunci "var" saat diperkenalkan, sekarang ini merupakan cara yang paling diterima untuk mendefinisikan variabel.
Jason

7
@Jasmine - Saya melihat sudut pandang Anda, meskipun saya pikir Anda secara tidak sengaja menamai tabel contoh Anda ke belakang. "TableOfInvoices" harus disingkat menjadi "Faktur," yang saya sukai. Anda mungkin sebaliknya berarti "Faktur," yang masuk akal untuk mempersingkat "Faktur."
Derek

280

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.

11
"Fields yang mewakili jenis data yang sama pada tabel yang berbeda harus dinamai sama. Jangan punya Zip di satu tabel dan ZipCode di yang lain." Ya ya jutaan kali ya. Bisakah Anda tahu bahwa basis data kami tidak dirancang seperti itu? Seseorang dapat dirujuk dengan berbagai cara, sangat menjengkelkan untuk dipertahankan. Saya selalu mematuhi aturan ini dalam basis data apa pun yang saya kendalikan dalam mendesain dan itu membuat hidup menjadi lebih sederhana.
HLGEM

87
Saya pikir kunci utama seharusnya "ID". Konvensi sederhana seperti itu membuat kunci utama dapat diprediksi dan dengan cepat dapat diidentifikasi. Namun, saya akan menambahkan nama tabel ("PersonID") ketika digunakan sebagai kunci asing di tabel lain. Konvensi ini dapat membantu membedakan antara kunci primer dan kunci asing dalam tabel yang sama.
Triynko

55
@Tryinko Menggunakan ID di semua tempat adalah LIVING NERAKA bagi siapa pun yang bergabung dengan beberapa tabel. Tidak ada cara yang mungkin bahwa sedikit keuntungan mengetahui ini adalah PK lebih besar daripada gangguan luar biasa dari pengulangan kembali kolom ID dang di setiap kueri berdarah berulang-ulang. Jika Anda ingin cara untuk menunjukkan PK dalam sebuah tabel, jadikan itu kolom pertama. Juga, menunjukkan FK dalam nama kolom ada di pikiran saya anti-pola yang benar-benar jahat.
ErikE

18
@Triynko jika Anda hanya menggunakan "ID", secara program tidak mungkin menentukan tabel miliknya. Dengan awalan nama tabel, Anda cukup memotong dua digit terakhir dari kunci primer dan tahu nama tabel miliknya melalui kode. Banyak kali orang-orang IT dan DBA tidak menyadari bahwa ada kelebihan coding untuk programmer dalam mendesain database dengan cara tertentu.
dallin

16
@ErikE Maksud saya, Anda tidak tahu apakah CustomerIDkunci utama dari Customertabel, atau kunci asing di beberapa tabel lainnya. Ini masalah kecil. Mengapa Anda ingin menggunakan nama yang buruk c? CustomerID = Customer.IDsangat 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.
Dave Cousineau

100

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.


17
@Emtucifor: Dalam bahasa Inggris, kita tidak mengatakan "Lihat semua orang di luar sana di tengah kerumunan orang itu!" Memiliki masalah konseptual dengan hal-hal yang banyak disebut oleh kata tunggal adalah yang diharapkan. Itu tidak biasa dan tidak layak. "Data" luar biasa dan sering digunakan untuk merujuk pada sepotong volume zat, seperti "kue". "Apakah kamu mau (sepotong) kue?" Memberi nama "Orang" pada tabel karena memuat informasi tentang banyak individu jauh lebih masuk akal daripada menamakannya "Orang". Kelas data bernama "Orang" untuk ROW masuk akal, seperti halnya nama kolom tunggal.
Triynko

6
@ Emtucifor: Pada akhirnya semua bahasa arbitrer dan konvensional. Saya hanya berargumen bahwa secara konvensional kami merujuk pada koleksi item sebagai jamak dari jenis item di dalamnya. Jadi kumpulan baris di mana setiap baris memiliki informasi tentang satu orang akan disebut sebagai kumpulan Orang. Tetapi jika Anda ingin menyebutnya sebagai kumpulan Orang, silakan saja.
Triynko

3
@ Emtucifor: Ya, lol. Memberi nama tabel "PersonCollection" akan sama dengan memberi nama "People". Kontras bahwa dengan menamai koleksi seperti itu hanya "Person", yang tidak masuk akal :)
Triynko

4
@ Emtucifor: Kalau begitu mari kita pikirkan dari sudut lain untuk meletakkan konvensi penamaan dalam konteks. Misalkan Anda memiliki kelas objek untuk mewakili baris dan tabel. "Person" jelas masuk akal untuk kelas yang mewakili deretan data. Jika meja Anda juga bernama "Orang", maka Anda mungkin memiliki konflik penamaan atau kebingungan. Saya hanya berpikir bahwa lebih masuk akal untuk memberi nama objek dengan pluralitas yang akurat. Baris dengan data tentang seseorang harus disebut Orang, dan tabel dengan informasi tentang orang atau banyak orang disebut Orang, PersonCollection, Orang, dll.
Triynko

5
@ Astaga. Yah, tidak ke arah mana pun Anda pergi. Jika Anda mengikuti cara saya, Anda bisa menggunakan tabel People sebagai "orang" dan memiliki orang SELECT. Masalah terpecahkan. ;-)
Matt Hamilton

73

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.


9
Khusus untuk nomor 3, kami memiliki sekelompok orang yang semuanya dipekerjakan dari perusahaan yang sama dan mereka mencoba untuk memaksakan standar penamaan lama mereka (yang tidak digunakan oleh kita semua) pada apa pun yang mereka lakukan. Sangat menyebalkan.
HLGEM

40
Tentu saja membuat SQL tidak terbaca; tapi saya pikir saya bisa menerjemahkan. cust_nm harus menjadi CustomerName , booking_dt harus BookingDate . reg_customer, saya tidak tahu apa itu.
Ian Boyd

3
@Ian. Tujuannya adalah agar Anda tetap pada konvensi penamaan yang biasa Anda gunakan, dan tetap konsisten. Saya SELALU tahu bahwa setiap bidang tanggal adalah _dt, bidang nama apa pun adalah _nm. 'reg' adalah contoh, dari sistem "pendaftaran" (pemesanan, pelanggan, dll) dan semua tabel terkait akan memiliki awalan yang sama. Tapi masing-masing untuk mereka sendiri ...
Guy

7
Saya setuju bahwa standar tertentu tidak sepenting memiliki standar yang konsisten. Tetapi beberapa standar salah. DB2 dan nama kolom seperti CSPTCN, CSPTLN, CSPTMN, CSDLN. Orang-orang harus mengetahui bahwa nama panjang telah ditemukan - kita dapat membuat hal-hal dapat dibaca.
Ian Boyd

17
Sepanjang tahun, saya telah menambahkan kolom baru di akhir tabel saya di aplikasi yang saya kembangkan dan pasarkan. Kadang-kadang, saya menggunakan nama bahasa Inggris di kolom saya, kadang-kadang saya menggunakan bahasa Spanyol dan kadang-kadang saya menggunakan kembali kolom untuk hal lain, alih-alih menghapusnya dan menambahkan kolom baru dengan nama deskriptif yang tepat untuk apa yang digunakan. Saya sengaja melakukan ini untuk OBFUSCATE kode sumber saya jika ada orang lain yang mencoba meretas atau merekayasa balik kode saya. Hanya saya yang bisa memahaminya, orang lain akan frustrasi! .. Dengan cara ini, mereka selalu harus mengandalkan saya untuk apa pun!
Frank R.

47
  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


5
Menambahkan beberapa kejelasan ke nomor 3 - awalan adalah cara menanamkan metadata ke dalam nama kolom. Seharusnya tidak perlu melakukan ini dalam DB modern untuk alasan yang sama seperti (terlalu sering) notasi Hungaria.
Mark McDonald

21
`pilih top 15 dari pesanan 'atau' pilih top 15 dari pesanan '? Yang terakhir adalah preferensi saya (manusia).
Ian Boyd

8
@Ian Boyd: Yap: PILIH TOP 100 * DARI Laporan R INNER GABUNG VisitReport VR ON R.ReportID = VR.ReportID. Itu semua tergantung pada bagaimana Anda memikirkannya. Jika Anda meletakkan gambar lemon pada tabung, Anda akan tahu ada lemon di dalamnya, tanpa perlu dua lemon di luar untuk menunjukkan bahwa itu bisa jamak. Tentu, Anda mungkin melabelinya dengan kata tertulis "lemon." Tapi mungkin saja "lemon". Untuk memperoleh sumber daya bernama "lemon", buka di sini.
ErikE

6
tambahkan $ 0,01 untuk menggunakan UpperCase dalam nama kolom dan tambahkan $ 0,01 untuk menggunakan garis bawah dalam nama kolom sehingga lebih mudah untuk membedakan nama kolom di depan mata. Total = sumbangan $ 0,02 saya untuk Anda!
Frank R.

6
"Tabel harus diberi nama setelah entitas yang diwakilinya" Tabel adalah kumpulan entitas. Sementara tabel juga merupakan entitas, itu adalah entitas tipe "Tabel" yang tidak ada gunanya untuk ditambahkan ke namanya.
Dipotong

34

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.


-1: Teks yang dirujuk tidak ada hubungannya dengan ISO / IEC 11179. Halaman wikipedia yang dirujuk tidak boleh dipercaya; baca standar yang sebenarnya sebagai gantinya ( metadata-standards.org/11179/#A5 )
mkadunc

@onedaywhen: Saya tidak cukup tahu tentang subjek untuk memperbaiki halaman wikipedia; Juga, halaman wikipedia tidak terlalu salah karena menyesatkan - ia tidak secara eksplisit mengatakan bahwa ISO / IEC 11179 mencakup konvensi penamaan basis data, ia hanya mengatakan bahwa "ISO / IEC 11179 dapat diterapkan ketika penamaan tabel dan kolom dalam suatu basis data relasional ". Kemudian melanjutkan untuk memberikan contoh konvensi penamaan yang mungkin digunakan untuk database relasional. Ini membuat Anda berpikir bahwa contohnya adalah sesuatu yang diambil dari standar, ketika itu benar-benar sesuatu yang dibuat oleh penulis artikel wikipedia.
mkadunc

27

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.


26

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.


1
SELECT * FROM people AS person WHERE person.name = 'Greg'terdengar paling alami bagi saya.
Kenmore

1
@Zuko Kebanyakan, konvensi penamaan untuk kunci utama tabel <table name><id>, misalnya PersonIDatau Person_IDlain - 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.
Tn. Blond


15

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%';

1
Maka Anda tidak bisa lagi reliably find every line of code that touches a particular column... Bukankah itu intinya?
raveren

6
@Raveren - Anda masih bisa. Jika semua yang Anda lakukan adalah "SELECT *", maka kueri tidak relevan untuk tujuan ini. Kapan / Jika nanti, Anda menggunakan hasil dari kueri itu, Anda harus menggunakan nama kolom untuk melakukan sesuatu dengan datanya, jadi itu adalah tempat yang perlu Anda khawatirkan dalam kode Anda, bukan pernyataan SQL.
Granger

Saya ingin tahu tentang situasi apa yang membutuhkan SELECT *? Saya tentu tidak ingin ada orang yang menggunakannya dalam kode produksi. Ya, ini berguna untuk kueri ad hoc dan untuk mengetahui bagian data mana yang membuat beberapa hasil kueri gabungan Anda menjadi aneh, tetapi saya tidak bisa memikirkan tempat di kode produksi yang diperlukan.
HLGEM

2
Kecuali jika Anda mengkode seluruh aplikasi dalam bahasa non-OO, maka memiliki lapisan ORM yang layak membuat argumen ini berlebihan.
Adam

6
Jadi karena jawaban ini, saya memutuskan untuk mencoba menggunakan awalan tabel pada proyek besar dan berpikir saya akan melaporkan kembali. Itu membuat tabel refactoring sangat mudah, yang luar biasa! Namun, itu adalah rasa sakit yang lebih besar daripada yang saya perkirakan. Database kami memiliki banyak tabel bernama kompleks. Mudah diingat Cust adalah awalan untuk Pelanggan, tetapi tidak semudah mengingat awalan untuk HazardVerificationMethod. Setiap kali saya menulis tabel atau bidang, saya harus berhenti sejenak untuk memikirkan awalan. Pada akhirnya saya memutuskan kecepatan dan kenyamanan lebih penting daripada kemampuan pencarian, tetapi saya merasa itu adalah pengalaman yang berharga.
dallin

15

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.


3
Apa-apaan ini CapitalCase?
ViRuSTriNiTy

@ViRuSTriNiTy yang dia maksudkanpascal case
marctrem

Keith, pada nomor # 3 saya melakukan keduanya, dan saya tidak konsisten (tapi saya ngelantur), tapi saya tidak mengerti mengapa itu buruk untuk memiliki nama kolom deskriptif selama tidak berlebihan, sama dengan meja, sebuah variabel, dll.
johnny

@ Johnny itu tidak buruk, karena itu, tidak diperlukan. Mengapa harus mengetik barang yang tidak harus Anda ketik? Juga sebagian intellisense terutama menggunakan awal nama, jadi jika Anda memiliki Product.ProductName, Product.ProductID, Product.ProductPricedll mengetik Product.Pmemberi Anda semua bidang yang diawali.
Keith

13

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.


1
mengenai # 4, PascalCase ... camelCase ... snake_case ...
Andrew

11

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 .

11
  1. Jelas menyimpan nama tabel tunggal, orang bukan orang
    1. Sama disini
    2. 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!
    3. Iya. Saya cenderung PascalCase semua nama tabel saya

28
OH TUHAN. TIDAK. Nama tabel PASTI jamak. Itu KOLEKSI. Ada banyak hal di dalamnya. "pilih * dari ORANG". Anda tidak memilih dari satu orang, Anda memilih dari beberapa ORANG!
Triynko

4
Saya selalu menyukai cara pernyataan pilih terdengar lebih baik jika jamak. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'tabel jamak, kolom tunggal. Lagi-lagi selalu masalah pendapat pribadi.
scunliffe

awalan tbl, qry dll bisa sangat berguna ketika Anda menangani metadata database, Jika Anda memeriksa objek dalam database yang memiliki konvensi penamaan yang cepat dan sederhana dapat mempercepat pemahaman secara dramatis
Cruachan

9

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

3
tabel adalah hubungan definisi. yang notabene singular. awalan menghisap. Pernahkah Anda perlu mengubah tabel menjadi tampilan atau sebaliknya? coba dengan awalan. apa bedanya jika itu adalah tampilan atau tabel?
William Jones

Awalan mungkin membantu di mana kami memiliki nama yang sama untuk dua objek - seperti fungsi dan prosedur tersimpan. Saya akan memiliki fungsi dengan nama 'GetApproverList' dan dengan nama yang sama saya ingin membuat prosedur tersimpan yang akan memanggil fungsi ini secara internal. Sql tidak akan mengizinkan pembuatan dua objek dengan nama yang sama.
Ravinder Singh


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

2
Perhatikan standar yang digunakan: tabel menampung banyak hal, pengguna memiliki satu nama depan, kata kunci T-SQL dalam huruf besar, definisi tabel dalam huruf Pascal.
Ian Boyd

3
kesalahan ketik: LastnameseharusnyaLastName
aminimalanimal

1
Nama tabel harus tunggal yaitu: Pengguna dan bukan Pengguna
AZ_

Dan perhatikan bagaimana nama tabel jamak; karena mereka memegang Pengguna , bukan Pengguna .
Ian Boyd

5

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.


2
Kawanan adalah sekelompok domba . Sebuah Useradalah tidak sekelompok pengguna.
EricRobertBrewer

4

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


2
Jadi Anda mengatakan bahwa tabel adalah entitas? Atau baris dalam tabel entitas? Bagi saya tabel adalah kumpulan baris - maka kumpulan entitas yang menyiratkan jamak.
Jason

4

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


1
Seperti yang Anda sebutkan, Anda tidak bisa mengandalkan setiap case memiliki table.column. Programmer akan lupa di satu tempat dan kemudian global Anda menemukan dan mengganti hanya merusak seluruh program Anda. Atau Anda akan membuatnya menjadi aturan dan seseorang akan berpikir ia memenuhi aturan dengan menggunakan alias tabel, sehingga sekali lagi menggagalkan temuan global. Selain itu, jika Anda ingin mengatur kode Anda dengan memiliki semacam kelas basis data (yang mana programmer akan baik), akan ada saat-saat ketika Anda hanya akan meneruskan nama kolom ke fungsi db atau hanya memiliki nama kolom saja di sebuah variabel.
dallin

2
@janb: Saya sangat mendukung jawaban Anda. Saya juga ingin menambahkan bahwa menggunakan pencarian teks untuk menemukan dependensi adalah cara biadab untuk menavigasi kode. Setelah orang menyingkirkan praktik pencarian barbar - mereka akan mulai menggunakan penamaan yang baik, yaitu table.column. Jadi masalahnya bukan penamaan gaya, masalahnya adalah alat yang buruk dibuat untuk orang barbar.
alpav

Argumen Anda salah. Masalahnya adalah ini bekerja dua arah dan tidak menambah keuntungan. Anda mengatakan, untuk menyelesaikan ini, selalu menulis table.column, karena Anda sudah menulis table_column. Nah, Anda juga bisa mengatakan hanya menulis table_column karena Anda sudah menulis table.column. Dengan kata lain, tidak ada perbedaan antara jawaban Anda selain dari itu memberikan kemungkinan kesalahan dan tidak menegakkan konvensi. Itulah alasan kami memiliki kata kunci 'pribadi'. Kami dapat mempercayai pemrogram untuk selalu menggunakan variabel kelas dengan benar, tetapi kata kunci memaksakannya dan menghilangkan kemungkinan kesalahan.
dallin

3

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


1
meskipun apa yang disarankan Oracle itu benar-benar berlawanan dengan tautan tautan di atas. temukan apa yang dikatakan Oracle di sini .. ss64.com/ora/syntax-naming.html
AZ_


Konvensi penamaan Oracle adalah yang paling lucu dari semuanya .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal

2

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.


-4

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

6
ChristianName ... itu konvensi yang aneh.
BobbyShaftoe

3
Nomor seri di atas meja Anda? Adakah yang serius berpikir ini masuk akal bekerja untuk para pengembang?
ErikE

Karena contoh ini mengangkatnya ... Saya pribadi menentang akronim huruf besar dalam nama tabel atau kolom, karena menurut saya membuatnya lebih sulit untuk dibaca. Jadi dalam hal ini, saya akan mengatakan StudentId lebih disukai daripada StudentID. Bukan masalah besar ketika akronim di bagian akhir, tetapi saya telah melihat banyak contoh dalam pekerjaan saya di mana akronim berada di bagian depan atau tengah nama, dan itu membuatnya lebih sulit untuk diuraikan dalam pikiran Anda. Mis: StudentABCSSN vs StudentAbcSsn.
redOktober13
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.