Saya memulai proyek baru dan ingin mendapatkan nama tabel dan kolom saya sejak awal. Misalnya saya selalu menggunakan jamak dalam nama tabel tetapi baru-baru ini belajar singular benar.

Jadi, jika saya mendapatkan tabel "pengguna" dan kemudian saya mendapatkan produk yang hanya dimiliki oleh pengguna, haruskah tabel tersebut dinamai "user_product" atau hanya "produk"? Ini adalah hubungan satu ke banyak.

Dan lebih jauh, jika saya ingin (karena alasan tertentu) beberapa deskripsi produk untuk setiap produk, apakah itu "user_product_description" atau "product_description" atau hanya "description"? Tentu saja dengan set kunci asing yang tepat .. Penamaan hanya deskripsi akan bermasalah karena saya juga bisa memiliki deskripsi pengguna atau deskripsi akun atau apa pun ..

Bagaimana jika saya ingin tabel relasional murni (banyak ke banyak) dengan hanya dua kolom, seperti apa ini? "user_stuff" atau mungkin sesuatu seperti "rel_user_stuff"? Dan jika yang pertama, apa yang membedakan ini dari, misalnya "user_product"?

Bantuan apa pun sangat dihargai dan jika ada semacam standar konvensi penamaan di luar sana yang Anda rekomendasikan, silakan tautkan.

Terima kasih

Tabel • Nama

singular yang baru dipelajari benar

Iya. Waspadalah terhadap para penyembah berhala. Jamak dalam nama tabel adalah tanda pasti seseorang yang belum membaca salah satu bahan standar dan tidak memiliki pengetahuan tentang teori basis data.

Beberapa hal indah tentang Standar adalah:

• mereka semua terintegrasi satu sama lain
• mereka bekerja bersama
• mereka ditulis oleh pikiran yang lebih besar dari kita, jadi kita tidak perlu berdebat dengannya.

Nama tabel standar mengacu pada setiap baris dalam tabel, yang digunakan dalam semua kata bertele-tele, bukan total isi tabel (kita tahu bahwa Customertabel berisi semua Pelanggan).

Hubungan, Frasa Verb

Dalam Database Relasional asli yang telah dimodelkan (sebagai lawan dari Sistem Pengarsipan Rekaman pra-1970 [ditandai dengan Record IDsyang diimplementasikan dalam wadah basis data SQL untuk kenyamanan):

• tabel adalah Subjek dari database, sehingga mereka adalah kata benda , sekali lagi, tunggal
• hubungan antara tabel adalah Tindakan yang terjadi di antara kata benda, sehingga kata kerja (artinya tidak diberi nomor atau dinamai secara sewenang-wenang)
• bahwa adalah yang Predikat
• semua itu dapat dibaca langsung dari model data (lihat contoh saya di akhir)
• (Predikat untuk tabel independen (orang tua teratas dalam hierarki) adalah tabel independen)
• sehingga Frase Verb dipilih dengan cermat, sehingga itu adalah istilah yang paling bermakna, dan generik dihindari (ini menjadi lebih mudah dengan pengalaman). Frase Verb penting selama pemodelan karena membantu dalam menyelesaikan model, yaitu. mengklarifikasi hubungan, mengidentifikasi kesalahan, dan memperbaiki nama tabel.

Diagram_A

Tentu saja, hubungan diimplementasikan dalam SQL sebagai CONSTRAINT FOREIGN KEYtabel anak (lebih lanjut, nanti). Berikut adalah Verb Phrase (dalam model), Predikat yang diwakilinya (untuk dibaca dari model), dan Nama Kendala FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tabel • Bahasa

Namun, ketika menggambarkan tabel, khususnya dalam bahasa teknis seperti Predikat, atau dokumentasi lainnya, gunakan bentuk tunggal dan bentuk jamak karena mereka alami dalam bahasa Inggris. Perlu diingat bahwa tabel tersebut dinamai untuk baris tunggal (relasi) dan bahasa tersebut mengacu pada setiap baris turunan (relasi turunan):

    Each Customer initiates zero-to-many SalesOrders

tidak

    Customers have zero-to-many SalesOrders 

Jadi, jika saya mendapatkan tabel "pengguna" dan kemudian saya mendapatkan produk yang hanya dimiliki oleh pengguna, haruskah tabel tersebut dinamai "produk-pengguna" atau hanya "produk"? Ini adalah hubungan satu ke banyak.

(Itu bukan pertanyaan penamaan-konvensi; itu adalah pertanyaan desain aa db.) Tidak masalah jika user::productadalah 1 :: n. Yang penting adalah apakah productentitas yang terpisah dan apakah itu merupakan Tabel Independen , yaitu. ia bisa eksis dengan sendirinya. Karena itu producttidak user_product.

Dan jika productada hanya dalam konteks suatu user, yaitu. Oleh karena itu, ini adalah Tabel Tanggunganuser_product .

Diagram_B

Dan lebih jauh, jika saya ingin (karena alasan tertentu) beberapa deskripsi produk untuk setiap produk, apakah itu "deskripsi pengguna produk" atau "deskripsi produk" atau hanya "deskripsi"? Tentu saja dengan set kunci asing yang tepat .. Penamaan deskripsi saja akan bermasalah karena saya juga bisa memiliki deskripsi pengguna atau deskripsi akun atau apa pun.

Betul sekali. Entah user_product_descriptionxor product_descriptionakan benar, berdasarkan yang di atas. Ini bukan untuk membedakannya dari yang lain xxxx_descriptions, tetapi untuk memberikan nama rasa di mana tempatnya, awalan menjadi tabel induk.

Bagaimana jika saya ingin tabel relasional murni (banyak ke banyak) dengan hanya dua kolom, seperti apa ini? "user-stuff" atau mungkin sesuatu seperti "rel-user-stuff"? Dan jika yang pertama, apa yang membedakan ini dari, misalnya "produk-pengguna"?

1. Semoga semua tabel dalam basis data relasional adalah tabel relasional murni, dinormalisasi. Tidak perlu mengidentifikasi bahwa dalam nama (jika tidak semua tabel akan menjadi rel_something).

2. Jika hanya berisi PK dari dua orang tua (yang menyelesaikan hubungan logis n :: n yang tidak ada sebagai entitas di tingkat logis, ke dalam tabel fisik ), itu adalah tabel asosiatif . Ya, biasanya nama adalah kombinasi dari dua nama tabel induk.

   • Perhatikan bahwa ini adalah kasus-kasus seperti yang diucapkan oleh Frasa Verb, dan dibaca sebagai, dari orangtua ke orangtua, mengabaikan tabel anak, karena satu-satunya tujuan hidupnya adalah untuk menghubungkan kedua orangtua.

     Diagram_C

   • Jika itu bukan Tabel Asosiatif (mis. Selain dari dua PK, itu berisi data), maka beri nama dengan tepat, dan Frasa Verb berlaku untuk itu, bukan orang tua di akhir hubungan.

     Diagram_D

3. Jika Anda berakhir dengan dua user_producttabel, maka itu adalah sinyal yang sangat keras bahwa Anda belum menormalkan data. Jadi kembali beberapa langkah dan lakukan itu, dan beri nama tabel secara akurat dan konsisten. Nama-nama kemudian akan menyelesaikan sendiri.

Konvensi penamaan

Bantuan apa pun sangat dihargai dan jika ada semacam standar konvensi penamaan di luar sana yang Anda rekomendasikan, silakan tautkan.

Apa yang Anda lakukan sangat penting, dan itu akan memengaruhi kemudahan penggunaan dan pemahaman di setiap tingkatan. Jadi, sangat baik untuk mendapatkan sebanyak mungkin pemahaman di awal. Relevansi dari sebagian besar ini tidak akan jelas, sampai Anda memulai pengkodean dalam SQL.

1. Kasing adalah item pertama yang ditangani. Semua topi tidak dapat diterima. Kasing campuran adalah normal, terutama jika tabel dapat diakses langsung oleh pengguna. Lihat model data saya. Perhatikan bahwa ketika pencari menggunakan beberapa NonSQL gila, yang hanya memiliki huruf kecil, saya memberikan bahwa, dalam hal ini saya menyertakan garis bawah (sesuai contoh Anda).

2. Pertahankan fokus data , bukan fokus aplikasi atau penggunaan. Bagaimanapun, setelah 2011, kami telah memiliki Arsitektur Terbuka sejak 1984, dan basis data seharusnya tidak tergantung pada aplikasi yang menggunakannya.

   Dengan begitu, saat mereka tumbuh, dan lebih dari satu aplikasi menggunakannya, penamaan akan tetap berarti, dan tidak perlu diperbaiki. (Database yang sepenuhnya tertanam dalam satu aplikasi bukan database.) Beri nama elemen data sebagai data saja.

3. Menjadi sangat perhatian, dan beri nama tabel dan kolom dengan sangat akurat . Jangan gunakan UpdatedDatejika itu DATETIMEtipe data, gunakan UpdatedDtm. Jangan gunakan _descriptionjika mengandung dosis.

4. Penting untuk konsisten di seluruh basis data. Jangan gunakan NumProductdi satu tempat untuk menunjukkan jumlah Produk dan ItemNoatau ItemNumdi tempat lain untuk menunjukkan jumlah Produk. Gunakan NumSomethinguntuk nomor-dari, dan SomethingNoatau SomethingIduntuk pengidentifikasi, secara konsisten.

5. Jangan awali nama kolom dengan nama tabel atau kode pendek, seperti user_first_name. SQL sudah menyediakan tablename sebagai kualifikasi:

       table_name.column_name  -- notice the dot
   

6. Pengecualian:

   • Pengecualian pertama untuk PK, mereka membutuhkan penanganan khusus karena Anda mengkodekannya dalam gabungan, sepanjang waktu, dan Anda ingin kunci menonjol dari kolom data. Selalu gunakan user_id, jangan pernah id.

     • Perhatikan bahwa ini bukan nama tabel yang digunakan sebagai awalan, tapi nama deskriptif yang tepat untuk komponen kunci: user_idadalah kolom yang mengidentifikasi pengguna, bukan iddari usertabel.
       • (Kecuali tentu saja dalam sistem pengarsipan catatan, di mana file diakses oleh pengganti dan tidak ada kunci relasional, ada satu dan hal yang sama).
     • Selalu gunakan nama yang sama persis untuk kolom kunci di mana pun PK dibawa (dimigrasikan) sebagai FK.
     • Oleh karena itu user_producttabel tersebut akan memiliki user_idkomponen PK-nya (user_id, product_no).
     • relevansi ini akan menjadi jelas ketika Anda mulai coding. Pertama, dengan idbanyak tabel, mudah dicampuradukkan dalam SQL coding. Kedua, siapa pun yang mengetahui bahwa pembuat kode awal tidak tahu apa yang ia coba lakukan. Keduanya mudah dicegah, jika kolom kunci diperlakukan seperti di atas.

   • Pengecualian kedua adalah ketika ada lebih dari satu FK yang mereferensikan tabel tabel induk yang sama, yang dibawa pada anak. Sesuai Model Relasional , gunakan Nama Peran untuk membedakan arti atau penggunaan, misalnya. AssemblyCodedan ComponentCodeuntuk dua PartCodes. Dan dalam hal ini, jangan tidak menggunakan terdiferensiasi PartCodeuntuk salah satu dari mereka. Tepatnya.

     Diagram_E

7. Awalan
   Di mana Anda memiliki lebih dari katakan 100 tabel, awali nama tabel dengan Area Subjek:

   REF_untuk tabel Referensi
   OE_untuk kluster Entri Pesanan, dll.

   Hanya di tingkat fisik, bukan yang logis (itu mengacaukan model).

8. Sufiks
   Jangan pernah menggunakan sufiks pada tabel, dan selalu gunakan sufiks pada yang lainnya. Itu berarti dalam penggunaan database yang logis dan normal, tidak ada garis bawah; tetapi pada sisi administrasi, garis bawah digunakan sebagai pemisah:

   _VLihat (dengan utama TableNamedi depan, tentu saja)
   _fkKunci Asing (nama kendala, bukan nama kolom) Transaksi Segmen
   _cacTembolok (fungsi atau fungsi tersimpan) Fungsi (non-transaksional), dll.
   _seg
_tr
_fn

   Formatnya adalah tabel atau nama FK, garis bawah, dan nama tindakan, garis bawah, dan akhirnya sufiks.

   Ini sangat penting karena ketika server memberi Anda pesan kesalahan:

   ____blah blah blah error on object_name

   Anda tahu persis objek apa yang dilanggar, dan apa yang coba ia lakukan:

   ____blah blah blah error on Customer_Add_tr

9. Kunci Asing (batasan, bukan kolom). Penamaan terbaik untuk FK adalah menggunakan Frase Verb (minus "masing-masing" dan kardinalitas).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Gunakan Parent_Child_fkurutan, bukan Child_Parent_fkkarena (a) itu muncul dalam urutan yang benar ketika Anda mencari mereka dan (b) kita selalu tahu anak yang terlibat, apa yang kita tebak adalah, orang tua mana. Pesan kesalahan kemudian menyenangkan:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Itu bekerja dengan baik untuk orang yang repot-repot memodelkan data mereka, di mana Frase Verb telah diidentifikasi. Selebihnya, sistem pengarsipan catatan, dll, gunakan Parent_Child_fk.

10. Indeks khusus, sehingga mereka memiliki konvensi penamaan mereka sendiri, terdiri dari, secara berurutan , masing-masing posisi karakter dari 1 hingga 3:

    UUnik, atau _untuk Non-unik
    CClustered, atau _untuk
    _pemisah non-clustered

    Untuk sisanya:

    • Jika kuncinya adalah satu kolom atau sangat sedikit kolom:
      ____ColumnNames

    • Jika kunci lebih dari beberapa kolom:
      ____ PKKunci Utama (sesuai model)
      ____ AK[*n*]Kunci Alternatif (istilah IDEF1X)

    Perhatikan bahwa nama tabel tidak diperlukan dalam nama indeks, karena selalu muncul sebagaitable_name.index_name.

    Jadi ketika Customer.UC_CustomerIdatau Product.U__AKmuncul dalam pesan kesalahan, ia memberi tahu Anda sesuatu yang bermakna. Saat Anda melihat indeks pada tabel, Anda dapat membedakannya dengan mudah.

11. Temukan seseorang yang berkualitas dan profesional dan ikuti mereka. Lihatlah desain mereka, dan pelajari dengan cermat konvensi penamaan yang mereka gunakan. Tanyakan kepada mereka pertanyaan spesifik tentang apa pun yang Anda tidak mengerti. Sebaliknya, jalankan seperti orang dari siapa pun yang menunjukkan sedikit hormat untuk penamaan konvensi atau standar. Inilah beberapa hal untuk Anda mulai:

    • Mereka berisi contoh nyata dari semua di atas. Ajukan pertanyaan tentang penamaan pertanyaan di utas ini.
    • Tentu saja, model menerapkan beberapa Standar lain , di luar konvensi penamaan; Anda dapat mengabaikannya untuk saat ini, atau merasa bebas untuk mengajukan pertanyaan baru yang spesifik .
    • Mereka masing-masing beberapa halaman, dukungan gambar sebaris di Stack Overflow untuk burung, dan mereka tidak memuat secara konsisten pada browser yang berbeda; jadi Anda harus mengklik tautannya.
    • Perhatikan bahwa file PDF memiliki navigasi lengkap, jadi klik tombol kaca biru, atau objek tempat ekspansi diidentifikasi:
    • Pembaca yang tidak terbiasa dengan Standar Pemodelan Relasional dapat menemukan Notasi IDEF1X bermanfaat.

Entri & Inventaris Pesanan dengan Alamat yang Sesuai Standar

Sistem Buletin antar kantor sederhana untuk PHP / MyNonSQL

Pemantauan Sensor dengan kemampuan Temporal penuh

Jawaban atas Pertanyaan

^{Itu tidak dapat dijawab secara wajar di ruang komentar.}

Larry Lustig:
... bahkan contoh paling sepele menunjukkan ...
Jika Pelanggan memiliki Produk nol ke banyak dan Produk memiliki Komponen satu ke banyak dan Komponen memiliki Pemasok satu ke banyak dan Pemasok menjual nol Komponen-ke-banyak dan SalesRep memiliki satu-ke-banyak Pelanggan apa nama "alami" tabel memegang Pelanggan, Produk, Komponen, dan Pemasok?

Ada dua masalah utama dalam komentar Anda:

1. Anda menyatakan contoh Anda sebagai "yang paling sepele", namun, itu sama sekali tidak. Dengan kontradiksi semacam itu, saya tidak yakin apakah Anda serius, jika secara teknis mampu.

2. Spekulasi "sepele" itu memiliki beberapa kesalahan Normalisasi (Desain DB) kotor.

   • Sampai Anda memperbaikinya, itu tidak wajar dan tidak normal, dan itu tidak masuk akal. Anda mungkin juga menamakannya abnormal_1, abnormal_2, dll.

   • Anda memiliki "pemasok" yang tidak memasok apa pun; referensi melingkar (ilegal, dan tidak perlu); pelanggan membeli produk tanpa instrumen komersial (seperti Faktur atau SalesOrder) sebagai dasar untuk pembelian (atau apakah pelanggan "memiliki" produk?); hubungan banyak ke banyak yang belum terselesaikan; dll.

   • Setelah itu dinormalisasi, dan tabel yang diperlukan diidentifikasi, nama mereka akan menjadi jelas. Tentu saja.

Bagaimanapun, saya akan mencoba untuk melayani permintaan Anda. Yang berarti saya harus menambahkan beberapa pengertian padanya, tidak tahu apa yang Anda maksudkan, jadi mohon bersabar. Kesalahan kotor terlalu banyak untuk dicantumkan, dan mengingat spesifikasi cadangan, saya tidak yakin telah memperbaiki semuanya.

• Saya akan berasumsi bahwa jika produk terdiri dari komponen, maka produk tersebut adalah rakitan, dan komponen tersebut digunakan di lebih dari satu rakitan.

• Lebih lanjut, karena "Pemasok menjual Komponen nol ke banyak", bahwa mereka tidak menjual produk atau rakitan, mereka hanya menjual komponen.

Spekulasi vs Model Normalisasi

Jika Anda tidak mengetahui, perbedaan antara sudut kuadrat (Independen) dan sudut bulat (Tergantung) adalah signifikan, silakan merujuk ke tautan Notasi IDEF1X. Demikian juga garis padat (Identifikasi) vs garis putus-putus (Non-mengidentifikasi).

... apa nama "alami" yang dimiliki tabel yang dimiliki oleh Pelanggan, Produk, Komponen, dan Pemasok?

• Pelanggan
• Produk
• Komponen (Atau, MajelisComponent, bagi mereka yang menyadari bahwa satu fakta mengidentifikasi yang lain)
• Pemasok

Sekarang saya telah menyelesaikan tabel, saya tidak mengerti masalah Anda. Mungkin Anda dapat memposting spesifik pertanyaan .

VoteCoffee:
Bagaimana Anda menangani skenario yang diposting Ronnis dalam contohnya di mana ada beberapa hubungan antara 2 tabel (user_likes_product, user_bought_product)? Saya mungkin salah paham, tetapi ini sepertinya menghasilkan duplikat nama tabel menggunakan konvensi yang Anda detail.

Dengan asumsi tidak ada kesalahan Normalisasi, User likes Productadalah predikat, bukan tabel. Jangan membingungkan mereka. Rujuk ke Jawaban saya, yang terkait dengan Subjek, Kata Kerja, dan Predikat, dan tanggapan saya terhadap Larry tepat di atas.

• Setiap tabel berisi sekumpulan Fakta (setiap baris adalah Fakta). Predikat (atau proposisi), bukan Fakta, mereka mungkin atau mungkin tidak benar.

  • The Relational Model ini didasarkan pada Pertama Orde Predikat Kalkulus (lebih dikenal sebagai Pertama Orde Logic). Predikat adalah kalimat klausa tunggal dalam bahasa Inggris yang sederhana dan tepat, yang mengevaluasi benar atau salah.

  • Lebih jauh, setiap tabel mewakili, atau implementasi dari, banyak Predikat, bukan satu.

• Kueri adalah tes Predikat (atau sejumlah Predikat, dirantai bersama) yang menghasilkan true (Fakta ada) atau false (Fakta tidak ada).

• Dengan demikian tabel harus dinamai, sebagaimana dirinci dalam Jawaban saya (konvensi penamaan), untuk baris, Fakta, dan Predikat harus didokumentasikan (dengan segala cara, ini adalah bagian dari dokumentasi basis data), tetapi sebagai daftar terpisah dari Predikat .

• Ini bukan saran bahwa mereka tidak penting. Mereka sangat penting, tetapi saya tidak akan menulisnya di sini.

• Cepat, kalau begitu. Karena Model Relasional didirikan pada FOPC, seluruh basis data dapat dikatakan sebagai satu set deklarasi FOPC, satu set Predikat. Tetapi (a) ada banyak jenis Predikat, dan (b) sebuah tabel tidak mewakili satu Predikat (itu adalah implementasi fisik dari banyak Predikat, dan dari berbagai jenis Predikat).

• Oleh karena itu penamaan tabel untuk "" Predikat yang diwakilinya "adalah konsep yang absurd.

• "Para ahli teori" hanya mengetahui beberapa Predikat, mereka tidak mengerti bahwa karena RM didirikan di FOL, seluruh basis data adalah seperangkat Predikat, dan dari berbagai jenis.

  • Dan tentu saja, mereka memilih yang absurd dari sedikit yang mereka tahu EXISTING_PERSON:; PERSON_IS_CALLED. Jika tidak begitu sedih, itu akan lucu.

  • Perhatikan juga bahwa nama tabel Standar atau atomik (penamaan baris) berfungsi dengan baik untuk semua kata-kata (termasuk semua Predikat yang dilampirkan pada tabel). Sebaliknya, nama "tabel mewakili predikat" idiot tidak bisa. Yang bagus untuk "ahli teori", yang mengerti sedikit tentang Predikat, tetapi terbelakang sebaliknya.

• Predikat yang relevan dengan model data, dinyatakan dalam model, mereka terdiri dari dua pesanan.

  1. Unary Predicate
     Set pertama adalah diagram , bukan teks: notasi itu sendiri . Ini termasuk berbagai Eksistensi; Berorientasi kendala; dan Penjelasan (atribut) Predikat.

     • Tentu saja, itu berarti hanya mereka yang dapat 'membaca' model data standar yang dapat membaca Predikat tersebut. Itulah sebabnya "para ahli teori", yang sangat lumpuh oleh pola pikir hanya teks mereka, tidak dapat membaca model data, mengapa mereka berpegang pada pola pikir hanya teks pra-1984 mereka.

  2. Binary Predicate
     Set kedua adalah yang membentuk hubungan antar Fakta. Ini adalah garis relasi. Frase Verb (diuraikan di atas) mengidentifikasi Predikat, proposisi , yang telah diterapkan (yang dapat diuji melalui kueri). Seseorang tidak bisa lebih eksplisit dari itu.

     • Oleh karena itu, bagi orang yang fasih dalam model data Standar, semua Predikat yang relevan , didokumentasikan dalam model. Mereka tidak memerlukan daftar Predikat terpisah (tetapi para pengguna, yang tidak bisa 'membaca' semuanya dari model data, lakukan!).

• Berikut adalah Model Data , di mana saya telah mendaftarkan Predikat. Saya telah memilih contoh itu karena menunjukkan Predikat Eksistensial, dll., Serta yang berhubungan, satu-satunya Predikat yang tidak terdaftar adalah Penjelas. Di sini, karena tingkat pembelajaran si pencari, saya memperlakukannya sebagai pengguna.

Oleh karena itu acara lebih dari satu tabel anak antara dua tabel induk tidak menjadi masalah, cukup beri nama mereka sebagai Fakta Eksistensial isi mereka, dan menormalkan nama-nama.

Aturan yang saya berikan untuk Frase Verb untuk nama hubungan untuk Tabel Asosiasi ikut bermain di sini. Berikut adalah diskusi Predikat vs Tabel , yang mencakup semua poin yang disebutkan, dalam ringkasan.

Untuk deskripsi singkat yang baik mengenai penggunaan Predikat yang tepat dan bagaimana menggunakannya (yang merupakan konteks yang berbeda dengan menanggapi komentar di sini), kunjungi jawaban ini , dan gulir ke bawah ke bagian Predikat .

Charles Burns:
Secara berurutan, maksud saya objek gaya-Oracle murni digunakan untuk menyimpan angka dan selanjutnya sesuai dengan beberapa aturan (misalnya "tambahkan 1"). Karena Oracle tidak memiliki tabel ID-otomatis, penggunaan tipikal saya adalah untuk menghasilkan ID unik untuk PK tabel. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Oke, itulah yang kita sebut tabel Key atau NextKey. Beri nama seperti itu. Jika Anda memiliki SubjectAreas, gunakan COM_NextKey untuk menunjukkannya umum di seluruh basis data.

Btw, itu adalah metode menghasilkan kunci yang sangat buruk. Tidak scalable sama sekali, tetapi kemudian dengan kinerja Oracle, itu mungkin "baik-baik saja". Lebih lanjut, ini menunjukkan bahwa basis data Anda penuh dengan pengganti, tidak berhubungan di bidang-bidang tersebut. Yang berarti kinerja yang sangat buruk dan kurangnya integritas.

Singular vs. Plural: Pilih satu dan pertahankan.

Kolom seharusnya tidak diawali / suffixed / infixed atau tetap diperbaiki dengan referensi ke fakta bahwa itu adalah kolom. Hal yang sama berlaku untuk tabel. Jangan beri nama tabel EMPLOYEE_T atau TBL_EMPLOYEES karena yang kedua diganti dengan tampilan, semuanya menjadi sangat membingungkan.

Jangan menanamkan informasi jenis dalam nama, seperti "vc_firstname" untuk varchar, atau "flavour_enum". Juga jangan menyematkan batasan pada nama kolom, seperti "department_fk" atau "employee_pk".

Sebenarnya, hal yang hanya baik tentang perbaikan * saya bisa memikirkan, adalah bahwa Anda dapat menggunakan kata-kata dicadangkan seperti where_t, tbl_order,user_vw . Tentu saja, dalam contoh-contoh itu, menggunakan jamak akan memecahkan masalah :)

Jangan menyebutkan semua kunci "ID". Kunci yang merujuk pada hal yang sama, harus memiliki nama yang sama di semua tabel. Kolom id pengguna bisa disebut USER_ID di tabel pengguna dan semua tabel yang mereferensikan pengguna. Satu-satunya waktu namanya diubah adalah ketika pengguna yang berbeda memainkan peran yang berbeda, seperti Message (sender_user_id, receiver_user_id). Ini sangat membantu ketika berhadapan dengan permintaan yang lebih besar.

Tentang CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

Secara umum lebih baik untuk memberi nama "tabel pemetaan" untuk mencocokkan hubungan yang dijelaskan daripada nama tabel yang direferensikan. Seorang pengguna dapat memiliki sejumlah hubungan dengan produk: user_likes_product, user_bought_product, user_wants_to_buy_product.

Tidak ada 'benar' tentang singular vs jamak - sebagian besar masalah selera.

Itu sebagian tergantung pada fokus Anda. Jika Anda menganggap tabel sebagai satu unit, ia memegang 'bentuk jamak' (karena memiliki banyak baris - sehingga nama jamak sesuai). Jika Anda menganggap nama tabel sebagai pengidentifikasi baris dalam sebuah tabel, Anda akan lebih memilih 'tunggal'. Ini berarti SQL Anda akan dianggap bekerja pada satu baris dari tabel. Tidak apa-apa, meskipun biasanya penyederhanaan berlebihan; SQL berfungsi pada set (lebih atau kurang). Namun, kita dapat memilih singular untuk jawaban atas pertanyaan ini.

1. Karena Anda mungkin memerlukan tabel 'pengguna', 'produk' lain, dan yang ketiga untuk menghubungkan pengguna ke produk, maka Anda memerlukan tabel 'user_product'.

2. Karena deskripsi tersebut berlaku untuk suatu produk, Anda akan menggunakan 'product_description'. Kecuali setiap pengguna menamai setiap produk untuk diri mereka sendiri ...

3. Tabel 'user_product' adalah (atau bisa jadi) contoh tabel dengan ID produk dan ID pengguna dan tidak banyak lagi. Anda menamai dua tabel atribut dengan cara umum yang sama: 'user_stuff'. Awalan dekoratif seperti 'rel_' tidak terlalu membantu. Anda akan melihat beberapa orang menggunakan 't_' di depan setiap nama tabel, misalnya. Itu tidak banyak membantu.

Bentuk jamak tidak buruk selama mereka digunakan secara konsisten - tetapi tunggal adalah pilihan saya.

Saya akan memberikan garis bawah kecuali jika Anda ingin menjabarkan hubungan banyak ke banyak; dan menggunakan modal awal karena membantu membedakan hal dalam ORM.

Tetapi ada banyak konvensi penamaan, jadi jika Anda ingin menggunakan garis bawah tidak apa-apa asalkan dilakukan secara konsisten.

Begitu:

User

UserProduct (it is a users products after all)

Jika hanya satu pengguna yang dapat memiliki produk apa pun maka

UserProductDescription

Tetapi jika produk dibagikan oleh pengguna:

ProductDescription

Jika Anda menyimpan garis bawah untuk hubungan banyak ke banyak, Anda dapat melakukan sesuatu seperti:

UserProduct_Stuff

untuk membentuk M-to-M antara UserProduct dan Stuff - tidak yakin dari pertanyaan, sifat pasti dari banyak-ke-banyak yang diperlukan.

Tidak ada yang lebih tepat untuk menggunakan bentuk tunggal daripada jamak, di mana Anda pernah mendengarnya? Saya lebih suka mengatakan bahwa bentuk jamak lebih umum untuk penamaan tabel database ... dan menurut saya juga lebih banyak logika. Tabel paling sering mengandung lebih dari satu baris;) Dalam model konseptual meskipun nama entitas sering dalam bentuk tunggal.

Tentang pertanyaan Anda, jika 'Produk' dan 'ProductDescription' adalah konsep dengan identitas (yaitu entitas) dalam model Anda, saya cukup memanggil tabel 'Produk' dan 'ProductDescription'. Untuk tabel yang digunakan untuk mengimplementasikan hubungan banyak ke banyak, saya paling sering menggunakan konvensi penamaan "SideA2SideB", misalnya "Student2Course".