ข้อตกลงการตั้งชื่อฐานข้อมูลตารางและคอลัมน์? [ปิด]

เมื่อใดก็ตามที่ฉันออกแบบฐานข้อมูลฉันมักจะสงสัยว่ามีวิธีที่ดีที่สุดในการตั้งชื่อรายการในฐานข้อมูลของฉัน บ่อยครั้งที่ฉันถามตัวเองคำถามต่อไปนี้:

1. ชื่อตารางควรเป็นพหูพจน์หรือไม่
2. ชื่อคอลัมน์ควรเป็นเอกพจน์หรือไม่
3. ฉันควรใส่คำนำหน้าตารางหรือคอลัมน์หรือไม่
4. ฉันควรใช้เคสใด ๆ ในการตั้งชื่อไอเท็มหรือไม่?

มีแนวทางที่แนะนำสำหรับการตั้งชื่อไอเท็มในฐานข้อมูลหรือไม่?

ฉันขอแนะนำให้ตรวจสอบฐานข้อมูลตัวอย่าง SQL Server ของ Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

ตัวอย่าง AdventureWorks ใช้แบบแผนการตั้งชื่อที่ชัดเจนและสอดคล้องกันมากซึ่งใช้ชื่อ schema สำหรับองค์กรของวัตถุฐานข้อมูล

1. ชื่อเอกพจน์สำหรับตาราง
2. ชื่อเอกพจน์สำหรับคอลัมน์
3. ชื่อสคีมาสำหรับคำนำหน้าตาราง (เช่น: SchemeName.TableName)
4. ปลอกปาสคาล (กรณีอูฐตอนบน)

ตอบช้ากว่าที่นี่ แต่พูดสั้น:

1. ความชอบของฉันคือพหูพจน์
2. ใช่
3. ตาราง : * โดยปกติ * ไม่มีคำนำหน้าใดดีที่สุด คอลัมน์ : ไม่
4. ทั้งตารางและคอลัมน์: PascalCase

รายละเอียดเพิ่มเติม:

(1) สิ่งที่คุณต้องทำ มีบางสิ่งที่คุณต้องทำบางอย่างทุกครั้ง แต่มีบางอย่าง

• ตั้งชื่อคีย์หลักของคุณโดยใช้รูปแบบ "[singularOfTableName] ID" นั่นคือไม่ว่าจะเป็นชื่อตารางของคุณเป็นลูกค้าหรือลูกค้า , คีย์หลักที่ควรจะเป็นลูกค้า
• นอกจากนี้คีย์ต่างประเทศจะต้องตั้งชื่ออย่างสม่ำเสมอในตารางที่แตกต่างกัน มันควรจะถูกกฎหมายที่จะเอาชนะคนที่ไม่ทำเช่นนี้ ฉันจะส่งว่าในขณะที่การกำหนดข้อ จำกัด ที่สำคัญต่างประเทศมักจะสำคัญที่สอดคล้องกันตั้งชื่อต่างประเทศที่สำคัญคือเสมอที่สำคัญ
• ฐานข้อมูลคุณต้องมีการประชุมภายใน แม้ว่าในส่วนต่อมาคุณจะเห็นว่าฉันมีความยืดหยุ่นสูง แต่ในการตั้งชื่อฐานข้อมูลจะต้องสอดคล้องกันมาก ไม่ว่าตารางของคุณสำหรับลูกค้าจะเรียกว่าลูกค้าหรือลูกค้ามีความสำคัญน้อยกว่าที่คุณทำแบบเดียวกันตลอดทั้งฐานข้อมูลเดียวกัน และคุณสามารถพลิกเหรียญเพื่อกำหนดวิธีการใช้เครื่องหมายขีดล่าง แต่แล้วคุณจะต้องเก็บไว้ใช้พวกเขาด้วยวิธีเดียวกัน หากคุณไม่ทำเช่นนี้คุณเป็นคนเลวที่ควรมีความนับถือตนเองต่ำ

(2) สิ่งที่คุณควรทำ

• เขตข้อมูลที่แสดงชนิดข้อมูลเดียวกันในตารางที่แตกต่างกันควรตั้งชื่อให้เหมือนกัน ไม่มี Zip บนโต๊ะหนึ่งและ ZipCode ที่อื่น
• หากต้องการแยกคำในชื่อตารางหรือคอลัมน์ของคุณให้ใช้ PascalCasing การใช้ camelCasing จะไม่เป็นปัญหาอย่างแท้จริง แต่นั่นไม่ใช่การประชุมและมันก็ดูตลก ฉันจะอยู่ที่ขีดล่างในอีกสักครู่ (คุณไม่สามารถใช้ ALLCAPS เหมือนในสมัยก่อน OBNOXIOUSTABLE.ANNOYING_COLUMN นั้นใช้ได้ใน DB2 เมื่อ 20 ปีที่แล้ว แต่ไม่ใช่ตอนนี้)
• อย่าย่อหรือย่อคำโดยไม่ตั้งใจ มันจะดีกว่าถ้าชื่อจะยาวและชัดเจนกว่าสั้นและสับสน ชื่อสั้นพิเศษเป็นโฮลดิ้งจากเวลาที่มืดกว่าและดุร้ายกว่า Cus_AddRef อะไรในโลกนี้ การอ้างอิงที่อยู่ผู้รับฝากทรัพย์สิน? ลูกค้าคืนเงินเพิ่มเติมหรือไม่ การอ้างอิงที่อยู่ที่กำหนดเอง?

(3) สิ่งที่คุณควรพิจารณา

• ฉันคิดว่าคุณควรมีชื่อพหูพจน์สำหรับตาราง บางคนคิดว่าเอกพจน์ อ่านข้อโต้แย้งที่อื่น อย่างไรก็ตามชื่อคอลัมน์ควรเป็นเอกพจน์ แม้ว่าคุณจะใช้ชื่อตารางจำนวนมากตารางที่แสดงชุดค่าผสมของตารางอื่นอาจอยู่ในรูปเอกพจน์ ตัวอย่างเช่นหากคุณมีตารางรายการส่งเสริมการขายและรายการตารางที่แสดงรายการที่เป็นส่วนหนึ่งของรายการส่งเสริมการขายอาจเป็นรายการส่งเสริมการขาย แต่มันอาจเป็นรายการส่งเสริมการขายที่ถูกต้องตามกฎหมาย (สะท้อนถึงความสัมพันธ์แบบหนึ่งต่อหลายคน)
• ใช้ขีดเส้นใต้อย่างสม่ำเสมอและเพื่อจุดประสงค์เฉพาะ ชื่อตารางทั่วไปควรชัดเจนเพียงพอกับ PascalCasing คุณไม่จำเป็นต้องขีดเส้นใต้เพื่อแยกคำ บันทึกขีดล่างอย่างใดอย่างหนึ่ง (a) เพื่อระบุตารางการเชื่อมโยงหรือ (b) สำหรับคำนำหน้าซึ่งฉันจะพูดถึงในหัวข้อย่อยถัดไป
• คำนำหน้าไม่ดีหรือไม่ดี มันมักจะไม่ดีที่สุด ใน db แรกหรือสองของคุณฉันจะไม่แนะนำให้ใช้คำนำหน้าสำหรับการจัดกลุ่มใจความทั่วไปของตาราง ตารางท้ายไม่เหมาะกับหมวดหมู่ของคุณได้อย่างง่ายดายและมันอาจทำให้ยากต่อการหาตาราง ด้วยประสบการณ์คุณสามารถวางแผนและใช้รูปแบบการเติมคำนำหน้าซึ่งทำได้ดีกว่าอันตราย ฉันทำงานใน db หนึ่งครั้งที่ตารางข้อมูลเริ่มต้นด้วยtbl , config tables ด้วยctbl , วิวด้วยvew , proc's sp , และfnของudfและอีกไม่กี่คน มันถูกใช้อย่างพิถีพิถันใช้งานอย่างสม่ำเสมอดังนั้นจึงใช้ได้ดี ครั้งเดียวที่คุณต้องการคำนำหน้าคือเมื่อคุณมีโซลูชันที่แยกต่างหากจริงๆซึ่งด้วยเหตุผลบางอย่างอยู่ในฐานข้อมูลเดียวกัน คำนำหน้าพวกเขาจะมีประโยชน์มากในการจัดกลุ่มตาราง การใส่คำนำหน้าก็โอเคสำหรับสถานการณ์พิเศษเช่นสำหรับตารางชั่วคราวที่คุณต้องการโดดเด่น
• ไม่ค่อยมาก (ถ้าเคย) คุณต้องการคำนำหน้าคอลัมน์

ตกลงเนื่องจากเราชั่งน้ำหนักด้วยความเห็น:

ฉันเชื่อว่าชื่อตารางควรเป็นพหูพจน์ ตารางเป็นการรวบรวม (ตาราง) ของเอนทิตี แต่ละแถวแสดงถึงเอนทิตีเดียวและตารางแสดงถึงการรวบรวม ดังนั้นฉันจะเรียกตารางของหน่วยงานบุคคลคน (หรือบุคคลสิ่งที่จะจินตนาการของคุณ)

สำหรับผู้ที่ต้องการเห็น "ชื่อเอนทิตี" เอกพจน์ในการสืบค้นนั่นคือสิ่งที่ฉันจะใช้ชื่อแทนตารางสำหรับ:

SELECT person.Name
FROM People person

บิตเช่น LINQ ของ "จากคนในคนเลือก person.Name"

สำหรับ 2, 3 และ 4 ฉันเห็นด้วยกับ @Lars

ฉันทำงานในทีมสนับสนุนฐานข้อมูลที่มี DBA สามตัวและตัวเลือกที่เราพิจารณาคือ:

1. มาตรฐานการตั้งชื่อใด ๆ ก็ดีกว่าไม่มีมาตรฐาน
2. ไม่มีมาตรฐาน "หนึ่งจริง" เราทุกคนมีการตั้งค่าของเรา
3. หากมีมาตรฐานอยู่แล้วให้ใช้ อย่าสร้างมาตรฐานอื่นหรือทำตัวให้เป็นมาตรฐานที่มีอยู่

เราใช้ชื่อเอกพจน์สำหรับตาราง ตารางมีแนวโน้มที่จะนำหน้าด้วยชื่อของระบบ (หรือตัวย่อ) สิ่งนี้มีประโยชน์หากความซับซ้อนของระบบในขณะที่คุณสามารถเปลี่ยนคำนำหน้าเพื่อจัดกลุ่มตารางเข้าด้วยกันอย่างมีเหตุผล (เช่น. reg_customer, reg_booking และ regadmin_limits)

สำหรับฟิลด์ที่เราคาดหวังว่าชื่อฟิลด์จะรวมคำนำหน้า / acryonm ของตาราง (เช่น cust_address1) และเราต้องการใช้ชุดคำต่อท้ายมาตรฐาน (_id สำหรับ PK, _cd สำหรับ "code", _nm สำหรับ "ชื่อ ", _nb สำหรับ" หมายเลข ", _dt สำหรับ" วันที่ ")

ชื่อของเขตข้อมูลคีย์ Foriegn ควรจะเหมือนกับเขตข้อมูลคีย์หลัก

กล่าวคือ

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

เมื่อพัฒนาโครงการใหม่ฉันขอแนะนำให้คุณเขียนชื่อเอนทิตีคำนำหน้าและคำย่อที่ต้องการทั้งหมดและมอบเอกสารนี้ให้กับนักพัฒนาของคุณ จากนั้นเมื่อพวกเขาตัดสินใจที่จะสร้างตารางใหม่พวกเขาสามารถอ้างถึงเอกสารมากกว่า "เดา" สิ่งที่ควรเรียกว่าตารางและเขตข้อมูล

1. ไม่ตารางควรตั้งชื่อตามเอนทิตีที่แสดง คนไม่ใช่บุคคลที่เป็นวิธีที่คุณจะอ้างถึงใครคนหนึ่งในบันทึกแสดง
2. อีกครั้งในสิ่งเดียวกัน คอลัมน์ FirstName ไม่ควรเรียกว่าชื่อจริง ทุกอย่างขึ้นอยู่กับสิ่งที่คุณต้องการแสดงด้วยคอลัมน์
3. NO
4. ใช่. กรณีเพื่อความชัดเจน หากคุณต้องการมีคอลัมน์เช่น "FirstName" การสร้างปลอกจะทำให้อ่านง่ายขึ้น

ตกลง. นั่นคือ $ 0.02 ของฉัน

ฉันชอบของการตั้งชื่อรูปแบบ ISO / IEC 11179 โดยสังเกตว่ามันเป็นแนวทางแทนที่จะเป็นแบบกำหนด

ดูชื่อองค์ประกอบข้อมูลใน Wikipedia :

"ตารางเป็นกลุ่มของเอนทิตีและปฏิบัติตามแนวทางการตั้งชื่อคอลเลกชันตามหลักการแล้วชื่อส่วนรวมจะถูกใช้: เช่น, บุคลากรพหูพจน์ถูกต้องเช่นกัน: พนักงานชื่อที่ไม่ถูกต้องประกอบด้วย: พนักงาน, tblEmployee และ EmployeeTable"

เช่นเคยมีข้อยกเว้นกฎเช่นตารางที่มีหนึ่งแถวที่แน่นอนอาจจะดีกว่าด้วยชื่อเอกพจน์เช่นตารางการกำหนดค่า และความสอดคล้องมีความสำคัญสูงสุด: ตรวจสอบว่าร้านค้าของคุณมีการประชุมหรือไม่และหากเป็นเช่นนั้นให้ทำตาม หากคุณไม่ชอบให้ทำเรื่องธุรกิจเปลี่ยนไปแทนที่จะเป็นคนเดียว

ฉันได้ยินข้อโต้แย้งตลอดเวลาว่าการให้คะแนนเป็นจำนวนมากหรือไม่นั้นเป็นเรื่องของรสนิยมส่วนตัวและไม่มีแนวปฏิบัติที่ดีที่สุด ฉันไม่เชื่อว่าเป็นเรื่องจริงโดยเฉพาะอย่างยิ่งในฐานะโปรแกรมเมอร์แทนที่จะเป็น DBA เท่าที่ฉันทราบไม่มีเหตุผลที่ถูกต้องตามกฎหมายที่จะทำให้ชื่อตารางเป็นชื่ออื่นนอกจาก "มันสมเหตุสมผลสำหรับฉันเพราะมันเป็นชุดของวัตถุ" ในขณะที่มีรหัสกำไรที่ถูกต้องตามกฎหมาย ตัวอย่างเช่น:

1. มันหลีกเลี่ยงข้อผิดพลาดและข้อผิดพลาดที่เกิดจากความสับสนพหูพจน์ โปรแกรมเมอร์ไม่เป็นที่รู้จักอย่างแน่นอนสำหรับความเชี่ยวชาญด้านการสะกดคำและการใช้คำบางคำทำให้เกิดความสับสน ตัวอย่างเช่นคำพหูพจน์สิ้นสุดใน 'es' หรือเพียงแค่ 's' หรือไม่ มันเป็นคนหรือคน? เมื่อคุณทำงานในโครงการที่มีทีมขนาดใหญ่สิ่งนี้อาจกลายเป็นปัญหาได้ ตัวอย่างเช่นอินสแตนซ์ที่สมาชิกในทีมใช้วิธีการที่ไม่ถูกต้องในการสร้างตารางที่เขาสร้างขึ้น เมื่อฉันมีปฏิสัมพันธ์กับตารางนี้มันถูกใช้จนหมดในรหัสที่ฉันไม่สามารถเข้าถึงหรือใช้เวลานานเกินไปในการแก้ไข ผลที่ได้คือฉันต้องจำที่จะสะกดตารางผิดทุกครั้งที่ฉันใช้มัน สิ่งที่คล้ายกันนี้เกิดขึ้นกับฉัน ยิ่งคุณสามารถทำให้สมาชิกทุกคนในทีมใช้งานได้อย่างสม่ำเสมอและง่ายดาย ชื่อตารางที่ถูกต้องโดยไม่มีข้อผิดพลาดหรือต้องค้นหาชื่อตารางตลอดเวลาดีกว่า เวอร์ชันเอกพจน์นั้นง่ายต่อการจัดการในสภาพแวดล้อมของทีม

2. หากคุณใช้ชื่อตารางรุ่นเอกพจน์และนำหน้าคีย์หลักด้วยชื่อตารางตอนนี้คุณมีข้อได้เปรียบในการพิจารณาชื่อตารางจากคีย์หลักหรือในทางกลับกันผ่านทางรหัสเพียงอย่างเดียว คุณสามารถกำหนดตัวแปรพร้อมชื่อตารางในนั้นเชื่อม "Id" ต่อท้ายและคุณมีคีย์หลักของตารางผ่านรหัสโดยไม่ต้องทำแบบสอบถามเพิ่มเติม หรือคุณสามารถตัด "Id" จากท้ายคีย์หลักเพื่อกำหนดชื่อตารางผ่านรหัส หากคุณใช้ "id" โดยไม่มีชื่อตารางสำหรับคีย์หลักคุณจะไม่สามารถระบุรหัสชื่อได้จากคีย์หลัก นอกจากนี้คนส่วนใหญ่ที่ทำหลายชื่อชื่อตารางและคอลัมน์ PK ส่วนนำหน้าด้วยชื่อตารางใช้เวอร์ชันเอกพจน์ของชื่อตารางใน PK (ตัวอย่างเช่นสถานะและ status_id)

3. หากคุณสร้างชื่อตารางเป็นเอกพจน์คุณสามารถให้ชื่อนั้นตรงกับชื่อคลาสที่พวกเขาเป็นตัวแทน อีกครั้งนี้สามารถลดความซับซ้อนของรหัสและช่วยให้คุณทำสิ่งที่เรียบร้อยจริงๆเช่น instantiating ชั้นเรียนโดยไม่มีอะไรนอกจากชื่อตาราง นอกจากนี้ยังทำให้โค้ดของคุณสอดคล้องกันมากขึ้นซึ่งนำไปสู่ ​​...

4. หากคุณทำให้ชื่อตารางเป็นเอกพจน์จะทำให้รูปแบบการตั้งชื่อของคุณสอดคล้องจัดระเบียบและง่ายต่อการบำรุงรักษาในทุกตำแหน่ง คุณรู้ว่าในทุกกรณีในรหัสของคุณไม่ว่าจะเป็นในชื่อคอลัมน์ชื่อคลาสหรือชื่อตารางมันเป็นชื่อที่แน่นอน สิ่งนี้ช่วยให้คุณทำการค้นหาทั่วโลกเพื่อดูทุกที่ที่มีการใช้ข้อมูล เมื่อคุณเขียนชื่อตารางจำนวนมากจะมีหลายกรณีที่คุณจะใช้ชื่อเอกพจน์ของชื่อตารางนั้น (คลาสจะเปลี่ยนเป็นในคีย์หลัก) มันสมเหตุสมผลที่จะไม่มีบางกรณีที่ข้อมูลของคุณเรียกว่าพหูพจน์และบางกรณีเป็นเอกพจน์

หากคุณสรุปชื่อตารางของคุณคุณสูญเสียความได้เปรียบทุกประเภทในการทำให้โค้ดของคุณฉลาดขึ้นและจัดการได้ง่ายขึ้น อาจมีบางกรณีที่คุณต้องมีตาราง / อาร์เรย์การค้นหาเพื่อแปลงชื่อตารางของคุณเป็นวัตถุหรือชื่อรหัสท้องถิ่นที่คุณสามารถหลีกเลี่ยงได้ ชื่อตารางเอกพจน์แม้ว่าอาจจะรู้สึกแปลก ๆ เล็กน้อยในตอนแรกเสนอข้อได้เปรียบที่สำคัญกว่าชื่อที่มีหลายฝ่ายและฉันเชื่อว่าเป็นแนวปฏิบัติที่ดีที่สุด

การตั้งค่าของเรา:

1. ชื่อตารางควรเป็นพหูพจน์หรือไม่
   ไม่เคย ข้อโต้แย้งว่ามันเป็นคอลเลกชันที่สมเหตุสมผล แต่คุณไม่เคยรู้ว่าสิ่งที่ตารางจะมี (0,1 หรือหลายรายการ) กฎพหูพจน์ทำให้การตั้งชื่อมีความซับซ้อนโดยไม่จำเป็น 1 เฮ้าส์, 2 บ้าน, เม้าส์เทียบกับหนู, คนเทียบกับคนและเรายังไม่ได้ดูภาษาอื่นเลย

   Update person set property = 'value'ทำหน้าที่กับแต่ละคนในตาราง
   Select * from person where person.name = 'Greg'ส่งกลับคอลเลกชัน / rowset ของแถวบุคคล

2. ชื่อคอลัมน์ควรเป็นเอกพจน์หรือไม่
   โดยปกติแล้วใช่ยกเว้นว่าคุณกำลังทำลายกฎการทำให้เป็นมาตรฐาน

3. ฉันควรใส่คำนำหน้าตารางหรือคอลัมน์หรือไม่
   ส่วนใหญ่เป็นการตั้งค่าแพลตฟอร์ม เราต้องการนำหน้าคอลัมน์ด้วยชื่อตาราง เราไม่ใช้คำนำหน้าตาราง แต่เราทำมุมมองคำนำหน้า (v_) และ storage_procedures (sp_ หรือ f_ (ฟังก์ชัน)) ที่ช่วยให้ผู้ที่ต้องการลอง vday_day.age ซึ่งเป็นเขตข้อมูลจากการคำนวณจริงในมุมมอง (ซึ่งไม่สามารถอัปเดตต่อไปได้)

   นอกจากนี้ยังเป็นวิธีที่ยอดเยี่ยมในการหลีกเลี่ยงการชนกันของคำหลัก

   มันทำให้รหัส verbose มากขึ้น แต่มักจะช่วยในการอ่าน

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... สามารถอ่านได้และชัดเจนมาก สิ่งนี้สามารถหลุดมือไปได้:

   customer.customer_customer_type_id

   บ่งบอกถึงความสัมพันธ์ระหว่างลูกค้าและตาราง customer_type ระบุคีย์หลักในตาราง customer_type (customer_type_id) และถ้าคุณเคยเห็น 'customer_customer_type_id' ในขณะที่การดีบักแบบสอบถามคุณรู้ทันทีว่ามันมาจาก (ตารางลูกค้า)

   หรือที่คุณมีความสัมพันธ์ MM ระหว่าง customer_type และ customer_category (เฉพาะบางประเภทเท่านั้นที่มีให้ในบางหมวดหมู่)

   customer_category_customer_type_id

   ... ยาวไปหน่อย (!)

4. ฉันควรใช้เคสใด ๆ ในการตั้งชื่อไอเท็มหรือไม่? ใช่ - ตัวพิมพ์เล็ก :) ด้วยเครื่องหมายขีดล่าง เหล่านี้เป็นแพลตฟอร์มที่อ่านได้และข้ามมาก เมื่อรวมกับ 3 ข้างต้นมันก็สมเหตุสมผล

   สิ่งเหล่านี้ส่วนใหญ่เป็นการกำหนดลักษณะ - ตราบใดที่คุณมีความสอดคล้องกันก็ควรจะคาดเดาได้สำหรับทุกคนที่ต้องอ่านมัน

ลองดูที่ ISO 11179-5: การตั้งชื่อและหลักการระบุคุณสามารถรับได้ที่นี่: http://metadata-standards.org/11179/#11179-5

ฉัน blogged เกี่ยวกับมันในขณะที่กลับมาที่นี่: ISO-11179 อนุสัญญาการตั้งชื่อ

ฉันรู้ว่าเกมนี้มาช้าและคำถามได้รับการตอบรับเป็นอย่างดี แต่ฉันต้องการเสนอความคิดเห็นของฉันใน # 3 เกี่ยวกับคำนำหน้าชื่อคอลัมน์

คอลัมน์ทั้งหมดควรตั้งชื่อด้วยคำนำหน้าที่ไม่ซ้ำกับตารางที่กำหนดไว้

เช่นตารางที่ได้รับ "ลูกค้า" และ "ที่อยู่" มาด้วยคำนำหน้า "cust" และ "addr" ตามลำดับ "ลูกค้า" จะมี "cust_id", "cust_name" ฯลฯ ในนั้น "ที่อยู่" จะมี "addr_id", "addr_cust_id" (FK กลับสู่ลูกค้า), "addr_street" ฯลฯ ในนั้น

เมื่อฉันถูกนำเสนอครั้งแรกกับมาตรฐานนี้ฉันถูกกำหนดตายต่อมัน ฉันเกลียดความคิด ฉันทนไม่ได้กับความคิดของการพิมพ์และความซ้ำซ้อนที่เพิ่มขึ้นทั้งหมด ตอนนี้ฉันมีประสบการณ์เพียงพอที่จะไม่กลับไป

ผลลัพธ์ของการทำเช่นนี้คือคอลัมน์ทั้งหมดในสคีมาฐานข้อมูลของคุณไม่ซ้ำกัน มีประโยชน์สำคัญอย่างหนึ่งต่อสิ่งนี้ซึ่งสำคัญกว่าการโต้แย้งทั้งหมด (ในความคิดของฉัน):

คุณสามารถค้นหาฐานรหัสทั้งหมดของคุณและค้นหารหัสบรรทัดทุกบรรทัดที่สัมผัสคอลัมน์ใด ๆ ได้อย่างน่าเชื่อถือ

ประโยชน์ที่ได้จาก # 1 นั้นใหญ่มากอย่างไม่น่าเชื่อ ฉันสามารถคัดค้านคอลัมน์และรู้ว่าต้องอัปเดตไฟล์ใดก่อนที่คอลัมน์จะสามารถลบออกอย่างปลอดภัยจากสคีมา ฉันสามารถเปลี่ยนความหมายของคอลัมน์และรู้ได้อย่างชัดเจนว่าโค้ดใดที่จำเป็นต้องได้รับการปรับโครงสร้างใหม่ หรือฉันสามารถบอกได้ว่าข้อมูลจากคอลัมน์นั้นแม้ถูกใช้ในส่วนใดส่วนหนึ่งของระบบ ฉันไม่สามารถนับจำนวนครั้งที่สิ่งนี้ทำให้โครงการขนาดใหญ่ที่อาจกลายเป็นโครงการที่เรียบง่ายหรือจำนวนชั่วโมงที่เราบันทึกไว้ในงานพัฒนา

อีกประโยชน์ที่ค่อนข้างน้อยคือคุณต้องใช้ชื่อแทนตารางเมื่อคุณเข้าร่วมด้วยตนเองเท่านั้น:

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) ไม่ชื่อตารางควรเป็นเอกพจน์

ในขณะที่ดูเหมือนจะสมเหตุสมผลสำหรับการเลือกอย่างง่าย ( select * from Orders) แต่ก็สมเหตุสมผลน้อยกว่าสำหรับ OO ที่เทียบเท่า ( Orders x = new Orders)

ตารางในฐานข้อมูลเป็นชุดของเอนทิตีนั้นมันสมเหตุสมผลดีกว่าเมื่อคุณใช้ set-logic:

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

บรรทัดสุดท้ายนั่นคือตรรกะที่แท้จริงของการเข้าร่วมดูสับสนกับชื่อตารางพหูพจน์

ฉันไม่แน่ใจเกี่ยวกับการใช้นามแฝงเสมอ (อย่างที่ Matt แนะนำ) ลบล้างสิ่งนั้น

2) พวกเขาควรจะเป็นเอกพจน์เนื่องจากพวกเขามีเพียง 1 แห่งเท่านั้น

3) ไม่เลยถ้าชื่อคอลัมน์นั้นคลุมเครือ (ดังที่กล่าวไว้ข้างต้นโดยที่ทั้งคู่มีคอลัมน์ชื่อ [Key]) ชื่อของตาราง (หรือนามแฝง) สามารถแยกแยะได้ดีพอ คุณต้องการให้คิวรีพิมพ์ได้อย่างรวดเร็วและเรียบง่าย - คำนำหน้าเพิ่มความซับซ้อนที่ไม่จำเป็น

4) สิ่งที่คุณต้องการฉันขอแนะนำ CapitalCase

ฉันไม่คิดว่าจะมีแนวทางที่แน่นอนหนึ่งชุดสำหรับสิ่งเหล่านี้

ตราบใดที่สิ่งที่คุณเลือกนั้นสอดคล้องกับแอปพลิเคชันหรือ DB ฉันไม่คิดว่ามันจะสำคัญ

ในความเห็นของฉัน:

1. ชื่อตารางควรเป็นพหูพจน์
2. ชื่อคอลัมน์ควรเป็นเอกพจน์
3. เลขที่
4. CamelCase (ที่ฉันต้องการ) หรือ underscore_separated สำหรับทั้งชื่อตารางและชื่อคอลัมน์

อย่างไรก็ตามเช่นเดียวกับที่ได้รับการกล่าวถึงการประชุมใด ๆ ก็ดีกว่าไม่มีการประชุม ไม่ว่าคุณจะเลือกทำอะไรให้ทำเอกสารเพื่อให้การดัดแปลงในอนาคตเป็นไปตามอนุสัญญาฉบับเดียวกัน

ฉันคิดว่าคุณและทีมของคุณจะได้รับคำตอบที่ดีที่สุดสำหรับคำถามแต่ละข้อ มันสำคัญยิ่งกว่าที่จะมีการตั้งชื่อการประชุมแล้วว่าการตั้งชื่อเป็นอย่างไร

เนื่องจากไม่มีคำตอบที่ถูกต้องคุณควรใช้เวลา (แต่ไม่มากเกินไป) และเลือกการประชุมของคุณเองและ - นี่คือส่วนสำคัญ - ยึดติดกับมัน

แน่นอนว่าคุณควรหาข้อมูลเกี่ยวกับมาตรฐานซึ่งเป็นสิ่งที่คุณต้องการ แต่ไม่ต้องกังวลหรือกังวลเกี่ยวกับจำนวนคำตอบต่าง ๆ ที่คุณอาจได้รับ: เลือกสิ่งที่ดีกว่าสำหรับคุณ

ในกรณีที่นี่คือคำตอบของฉัน:

1. ใช่. ตารางเป็นกลุ่มของระเบียน , ครูหรือนักแสดงเพื่อให้ ... พหูพจน์
2. ใช่.
3. ฉันไม่ได้ใช้พวกเขา
4. ฐานข้อมูลที่ฉันใช้บ่อย - Firebird - เก็บทุกอย่างไว้เป็นตัวใหญ่ดังนั้นมันจึงไม่สำคัญ อย่างไรก็ตามเมื่อฉันเขียนโปรแกรมฉันเขียนชื่อในแบบที่อ่านง่ายกว่าเช่นปล่อยปี

1. แน่นอนเก็บชื่อตารางเอกพจน์คนไม่ใช่คน
   2. กันที่นี่
   3. ไม่ฉันเคยเห็นคำนำหน้าน่ากลัวอยู่บ้างจนถึงขั้นที่กล่าวถึงสิ่งที่จัดการคือตาราง (tbl_) หรือขั้นตอนการจัดเก็บข้อมูลผู้ใช้ (usp_) ตามด้วยชื่อฐานข้อมูล ... อย่าทำ!
   4. ใช่. ฉันมักจะ PascalCase ชื่อตารางทั้งหมดของฉัน

อนุสัญญาการตั้งชื่อช่วยให้ทีมพัฒนาสามารถออกแบบการค้นพบและการบำรุงรักษาที่เป็นหัวใจของโครงการ

รูปแบบการตั้งชื่อที่ดีต้องใช้เวลาในการพัฒนา แต่เมื่ออยู่ในตำแหน่งแล้วจะช่วยให้ทีมก้าวไปข้างหน้าด้วยภาษาทั่วไป แบบแผนการตั้งชื่อที่ดีจะเติบโตแบบอินทรีย์กับโครงการ รูปแบบการตั้งชื่อที่ดีสามารถจัดการกับการเปลี่ยนแปลงในช่วงระยะเวลาที่ยาวที่สุดและสำคัญที่สุดของวงจรชีวิตซอฟต์แวร์ - การจัดการบริการในการผลิต

นี่คือคำตอบของฉัน:

1. ใช่ชื่อตารางควรเป็นพหูพจน์เมื่อพวกเขาหมายถึงชุดของการซื้อขาย , หลักทรัพย์หรือคู่สัญญาเช่น
2. ใช่.
3. ใช่. ตาราง SQL นำหน้าด้วย tb_, มุมมองนำหน้า vw_, โพรซีเดอร์ที่เก็บไว้จะนำหน้า usp_ และทริกเกอร์จะนำหน้า tg_ ตามด้วยชื่อฐานข้อมูล
4. ชื่อคอลัมน์ควรเป็นตัวพิมพ์เล็กคั่นด้วยเครื่องหมายขีดล่าง

การตั้งชื่อนั้นยาก แต่ในทุก ๆ องค์กรมีใครบางคนที่สามารถตั้งชื่อสิ่งต่าง ๆ และในทีมซอฟต์แวร์ทุกคนควรมีคนที่รับผิดชอบมาตรฐาน namings และทำให้มั่นใจว่าปัญหาการตั้งชื่อเช่นsec_id , sec_valueและsecurity_idได้รับการแก้ไขก่อน .

ดังนั้นสิ่งที่เป็นหลักการพื้นฐานของการตั้งชื่อที่ดีและมาตรฐาน: -

• ใช้ภาษาของลูกค้าและโดเมนโซลูชันของคุณ
• จงพรรณนา
• คงเส้นคงวา
• Disambiguate, reflect and refactor
• อย่าใช้ตัวย่อยกเว้นว่าชัดเจนสำหรับทุกคน
• อย่าใช้คำหลักที่สงวนไว้ของ SQL เป็นชื่อคอลัมน์

นี่คือลิงค์ที่มีตัวเลือกน้อย ฉันกำลังค้นหาสเปคง่าย ๆ ที่ฉันสามารถติดตามได้แทนที่จะต้องพึ่งพาข้อกำหนดที่กำหนดไว้เพียงบางส่วน

http://justinsomnia.org/writings/naming_conventions.html

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

ชื่อตารางควรเป็นเอกพจน์เนื่องจากเป็นตัวแทนของชุดวัตถุ อย่างที่คุณบอกว่าฝูงจะกำหนดกลุ่มของแกะหรือฝูงจะกำหนดกลุ่มของนก ไม่จำเป็นต้องใช้พหูพจน์ เมื่อชื่อตารางเป็นองค์ประกอบของสองชื่อและหลักการตั้งชื่อเป็นพหูพจน์มันยากที่จะรู้ว่าชื่อพหูพจน์ควรเป็นคำแรกหรือคำที่สองหรือทั้งสองอย่าง มันเป็นตรรกะ - วัตถุวัตถุไม่ใช่วัตถุ หรือ TableName.column ไม่ใช่ TableNames.column Microsoft SQL ไม่คำนึงถึงขนาดตัวพิมพ์และตัวอักษรดังนั้นจึงง่ายต่อการอ่านชื่อตารางหากใช้ตัวอักษรตัวพิมพ์ใหญ่เพื่อแยกชื่อตารางหรือคอลัมน์เมื่อประกอบด้วยสองชื่อหรือมากกว่า

ชื่อตาราง:ควรเป็นเอกพจน์เนื่องจากเป็นเอนทิตีเอกพจน์แทนวัตถุในโลกแห่งความจริงไม่ใช่วัตถุซึ่งเป็นเอกพจน์

ชื่อคอลัมน์:ควรเป็นเอกพจน์เท่านั้นจากนั้นจะบ่งบอกว่ามันจะมีค่าอะตอมมิกและจะยืนยันกับทฤษฎีการทำให้เป็นมาตรฐาน หากมีคุณสมบัติประเภทเดียวกันจำนวน n คุณสมบัติเหล่านั้นควรต่อท้ายด้วย 1, 2, ... , n และอื่น ๆ

คำนำหน้าตาราง / คอลัมน์: เป็นหัวข้อใหญ่ที่จะกล่าวถึงในภายหลัง

ปลอก: ควรเป็นกรณีอูฐ

Patrick Karcherเพื่อนของฉันฉันขอให้คุณโปรดอย่าเขียนสิ่งใดที่อาจเป็นที่น่ารังเกียจแก่ใครบางคนอย่างที่คุณเขียนว่า "•ยิ่งไปกว่านั้นกุญแจต่างประเทศจะต้องตั้งชื่ออย่างสม่ำเสมอในตารางที่แตกต่างกัน ทำเช่นนี้.". ฉันไม่เคยทำผิดพลาดมาก่อนเพื่อนแพทริคของฉัน แต่ฉันเขียนโดยทั่วไป เกิดอะไรขึ้นถ้าพวกเขาวางแผนที่จะเอาชนะคุณด้วยสิ่งนี้? :)

สายไปงานเลี้ยง แต่ฉันยังต้องการเพิ่มสองเซ็นต์ของฉันเกี่ยวกับคำนำหน้าคอลัมน์

ดูเหมือนจะมีสองข้อโต้แย้งหลักสำหรับการใช้มาตรฐานการตั้งชื่อ table_column (หรือ tableColumn) สำหรับคอลัมน์ทั้งสองตามข้อเท็จจริงที่ว่าชื่อคอลัมน์นั้นจะไม่ซ้ำกันในฐานข้อมูลทั้งหมดของคุณ:

1) คุณไม่จำเป็นต้องระบุชื่อตารางและ / หรือชื่อแทนคอลัมน์ในแบบสอบถามของคุณตลอดเวลา

2) คุณสามารถค้นหาชื่อรหัสทั้งหมดได้อย่างง่ายดาย

ฉันคิดว่าข้อโต้แย้งทั้งสองมีข้อบกพร่อง วิธีแก้ปัญหาสำหรับทั้งสองปัญหาโดยไม่ใช้คำนำหน้าเป็นเรื่องง่าย นี่คือข้อเสนอของฉัน:

ใช้ชื่อตารางใน SQL ของคุณเสมอ เช่นใช้ table.column แทนคอลัมน์เสมอ

เห็นได้ชัดว่ามันแก้ได้ 2) ในขณะที่คุณสามารถค้นหา table.column แทน table_column

แต่ฉันได้ยินเสียงกรีดร้องของคุณมันแก้ได้อย่างไร 1) มันเกี่ยวกับการหลีกเลี่ยงสิ่งนี้ ใช่มันเป็น แต่การแก้ปัญหาคือข้อบกพร่องอย่างน่ากลัว ทำไม? วิธีการแก้ปัญหาคำนำหน้าจะลดลงไปที่:
เพื่อหลีกเลี่ยงการระบุ table.column เมื่อมีความกำกวมให้ตั้งชื่อคอลัมน์ทั้งหมดของคุณ table_column!
แต่นี่หมายความว่าคุณจะต้องเขียนชื่อคอลัมน์ทุกครั้งที่คุณระบุคอลัมน์ แต่ถ้าคุณต้องทำอย่างนั้นต่อไปประโยชน์ที่จะได้จากการเขียนลงในตารางคืออะไร? แน่นอนไม่มีประโยชน์มันเป็นจำนวนอักขระที่แน่นอนที่จะพิมพ์

แก้ไข: ใช่ฉันรู้ว่าการตั้งชื่อคอลัมน์ด้วยคำนำหน้าบังคับใช้งานที่ถูกต้องในขณะที่วิธีการของฉันอาศัยโปรแกรมเมอร์

ข้อตกลงการตั้งชื่อฐานข้อมูลที่จำเป็น (และสไตล์) (คลิกที่นี่สำหรับคำอธิบายโดยละเอียดเพิ่มเติม)

ชื่อตารางเลือกชื่อที่สั้นและไม่คลุมเครือโดยใช้คำไม่เกินหนึ่งหรือสองคำแยกแยะตารางต่าง ๆ ได้อย่างง่ายดายอำนวยความสะดวกในการตั้งชื่อของชื่อฟิลด์ที่ไม่ซ้ำกันเช่นเดียวกับการค้นหาและการเชื่อมโยงตาราง สำหรับการประชุมนี้ แต่คนส่วนใหญ่ชอบชื่อตารางเป็นพหูพจน์ดังนั้นฉันได้ทำให้ท่าทางของฉันอ่อนลง) ... ตามลิงค์ด้านบนโปรด

ชื่อตารางเอกพจน์ สมมติว่าคุณกำลังจำลอง realtionship ระหว่างใครบางคนและที่อยู่ของพวกเขา ตัวอย่างเช่นหากคุณกำลังอ่านแบบจำลองคุณต้องการให้ 'แต่ละคนอาจอยู่ที่ 0,1 หรือที่อยู่หลายแห่ง' หรือ 'แต่ละคนอาจอาศัยอยู่ที่ 0,1 หรือที่อยู่หลายแห่ง' ฉันคิดว่ามันง่ายกว่าที่จะพูดคำพหูพจน์แทนที่จะต้องใช้ถ้อยคำใหม่เป็นคน คำนามรวมส่วนใหญ่มักจะไม่เห็นด้วยกับรุ่นเอกพจน์

--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
);

นี่คือการประชุมที่ฉันได้รับการสอน แต่คุณควรปรับให้เข้ากับสิ่งที่คุณใช้ในการพัฒนา

1. พหูพจน์. มันคือชุดของหน่วยงาน
2. ใช่. คุณลักษณะนี้เป็นตัวแทนของคุณสมบัติเอกพจน์ของเอนทิตี
3. ใช่ชื่อตารางคำนำหน้าช่วยให้สามารถตั้งชื่อติดตามดัชนีและชื่อแทนตารางได้อย่างง่ายดาย
4. Pascal Case สำหรับชื่อตารางและคอลัมน์คำนำหน้า + ALL caps สำหรับดัชนีและข้อ จำกัด