ฉันควรทำตามมาตรฐานใดเมื่อตั้งชื่อตารางและมุมมอง

20

ฉันควรทำตามมาตรฐานใดเมื่อตั้งชื่อตารางและมุมมอง ยกตัวอย่างเช่นเป็นความคิดที่ดีที่จะวางบางสิ่งเช่น tbl_ ไว้ที่จุดเริ่มต้นของชื่อตารางหรือไม่ ฉันควรกำหนดตารางรหัส / ค้นหาในบางวิธีเช่น ct_, lut_ หรือ codes_ หรือไม่ มีคนอื่นทำหรือไม่?

ฉันใช้ MS SQL Server และมีฐานข้อมูลจำนวนมากที่มีตารางจำนวนมากดังนั้นมันก็ดีที่มีสิ่งที่เราสามารถใช้เป็นมาตรฐานที่มีเหตุผลสนับสนุนบางอย่าง

relational-theory naming-convention

— เบ ธ ไวท์เซล
แหล่งที่มา

29

ตกลงก่อนอื่นอย่าวาง tbl ไว้หน้าชื่อของตาราง มันเป็นตารางตอนนี้เราก็เรียบร้อยแล้ว นั่นเรียกว่าสัญลักษณ์ของฮังการีและผู้คนหยุดทำเมื่อ 5+ ปีก่อน

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

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

— mrdenny
แหล่งที่มา

11

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

— Marian

1

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

— mrdenny

2

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

— Beth Whitezel

2

คำตอบของนายเดนนี่และผู้ติดตามคนต่อไปนี้ได้รับการสนับสนุนโดยสิ่งนี้: dba4life.blogspot.com/2007/11/…

1

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

— BillThor

13

เราใช้สกีมา (คิดว่าเป็นเนมสเปซใน SQL) สำหรับทั้งการอนุญาตและการจัดกลุ่ม ดังนั้นแทนที่จะเป็น "tbl" ฯลฯ เรามี

Data.Thing
Data.ThingHistory
Data.Stuff

ไม่มีรหัสใดที่จะเข้าสู่สคีมาข้อมูล ไม่มีตารางอยู่นอก Data schema สิ่งนี้สามารถขยายออกไปอีกเพื่อให้มีสคีมาการค้นหาหรือ Staging หากคุณต้องการ

สำหรับมุมมองที่เราใช้vwแต่นี่คือการแยกความแตกต่างจากตารางใน SQL Server 2000 และตอนนี้มันเป็นมรดก

— GBN
แหล่งที่มา

3

+1 สำหรับสกีมาที่แนะนำ สิ่งนี้จะมีประโยชน์ในขณะที่รักษาฐานข้อมูลขนาดใหญ่ที่มีตาราง 100s เราใช้สกีมาสำหรับการจัดกลุ่มการทำงานเช่นกันเช่นเดียวกับใน AdventureWorks db

— CoderHawk

5

โดยส่วนตัวฉันเป็นแฟนตัวยงของFanö Bedingungซึ่งหมายความว่าที่นี่ไม่มีชื่อที่อนุญาตให้เป็นจุดเริ่มต้นของชื่อที่ถูกต้องได้อีก

และอย่างที่สองระยะห่างระหว่าง Hamming ระหว่างสองชื่อนั้นดีกว่าตัวอักษรที่แตกต่างกันหนึ่งตัว

ใช่นั่นเป็นกฎจากยุคดิจิตอล แต่มันทำให้ชีวิตง่ายขึ้น

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

— bernd_k
แหล่งที่มา

2

เมื่อการรู้จำเสียงกลายเป็นเรื่องจริงฉันก็จะโมโหอยู่ดี :-)

— Beth Whitezel

เฉพาะในกรณีที่คุณใช้การสนับสนุนทางโทรศัพท์

— bernd_k

1

เมื่อการรู้จำเสียงเกิดขึ้นฉันจะกลายเป็นคนขับรถบรรทุก นั่นเป็นฤาษีที่บ้าคลั่ง

— mrdenny

คุณสามารถอธิบายรายละเอียดเพิ่มเติม (อาจมีตัวอย่าง) ว่า "Fano Bedingung" คืออะไร?

— Nick Chammas

1

@NickChammas ผมคิดว่าในภาษาอังกฤษเราเรียกว่าแชนนอน-โน่เข้ารหัส

— เลนซามูเอลแมคลีนเลน

2

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

ในร้านของฉันเราปฏิบัติตามกฎต่อไปนี้:

เราแยกคำด้วยเครื่องหมายขีดล่างและใช้ตัวอักษรพิมพ์เล็กทั้งหมด
ชื่อตารางของเราอธิบายว่าพวกเขาคืออะไร: dbo.person, dbo.invoice
ชื่อตารางแบบหลายต่อหลายชื่อของเรายังอธิบายถึงสิ่งที่พวกเขา (ด้วยการเพิ่มmmเพื่อระบุความสัมพันธ์หลายต่อหลายคนที่ถูกแมป: dbo.person_mm_address ขั้นตอนการจัดเก็บที่ผู้ใช้กำหนดของเราอธิบายทั้งวัตถุและการดำเนินการ: usp_person_select , usp_address_select_by_city มุมมองและฟังก์ชั่นของเราเป็นไปตามกฎเดียวกันกับขั้นตอนการจัดเก็บดัชนีของเราประกอบด้วยตารางคอลัมน์สำคัญ (ตามลำดับ) และการบ่งชี้ของคลัสเตอร์ / ที่ไม่คลัสเตอร์: ix_person_last_name_first_name_nc

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

ฉันหวังว่าวิธีนี้จะช่วยได้บ้าง

— แมตต์เอ็ม
แหล่งที่มา

2

ฉันพอใจกับสิ่งเหล่านี้มาหลายปีแล้ว

ชื่อตาราง: ตัวพิมพ์เล็กและขีดล่าง, เอกพจน์ {ลูกค้า, ผลิตภัณฑ์}
ชื่อตารางสำหรับความสัมพันธ์แบบหลายต่อหลาย: tablename1_tablename2: {customer_product}
views: ตัวพิมพ์เล็กเพิ่ม v ท้าย {customerv, productv, product_groupv}
procudures ที่เก็บไว้: ชื่อตารางและฟังก์ชั่น {customer_select, customer_insert, customer_delete, customer_update}

หากคุณมีแพ็คเกจโฮสติ้งที่ใช้ร่วมกันราคาถูกคุณจะต้องใช้ตัวย่อของโครงการต่อหน้าวัตถุทั้งหมดของคุณเช่นเว็บไซต์ผู้ดูแลฐานข้อมูล da_users, da_questions

— UğurGümüşhan
แหล่งที่มา

ทำไมproduct_groupvและไม่ใช่product_group_vสำหรับมุมมอง (ถ้าคุณยืนยันในมุมมองและตารางที่บิดเบือน)

— ypercubeᵀᴹ

@ypercube เพราะฉันขี้เกียจเกินกว่าที่จะพิมพ์เครื่องหมายขีดล่างพิเศษหนึ่งตัวและฉันพิมพ์ผิดได้ง่าย ฉันอ่านคำศัพท์ได้ง่ายขึ้นเมื่อฉันใช้เครื่องหมายขีดล่างและฉันใช้ v เพื่อแยกมุมมองออกจากตารางและ v ไม่ใช่คำศัพท์ดังนั้นฉันจึงไม่ใช้ขีดเส้นใต้ .. ดูเหมือนไม่สอดคล้องใช่ แต่ฉันพบว่ารูปแบบนี้ใช้งานได้จริง

— UğurGümüşhan