มีแบบแผนการตั้งชื่อสำหรับ MySQL หรือไม่?

163

นี่คือวิธีที่ฉันทำ:

ชื่อตารางเป็นกรณีที่ต่ำกว่าขีดล่างใช้ถ้อยคำที่แยกต่างหากและเป็นเอกพจน์ (เช่นfoo, foo_barฯลฯ
ฉันโดยทั่วไป (ไม่เสมอไป) มีการเพิ่ม PK อัตโนมัติ ผมใช้การประชุมดังต่อไปนี้tablename_id(เช่นfoo_id, foo_bar_idฯลฯ )
เมื่อตารางมีคอลัมน์ที่เป็นคีย์ต่างประเทศฉันเพิ่งคัดลอกชื่อคอลัมน์ของคีย์นั้นจากตารางใดก็ตามที่มาจาก ตัวอย่างเช่นสมมติว่าตารางfoo_barมี FK foo_id(ซึ่งfoo_idเป็น PK ของfoo)
เมื่อกำหนด FK เพื่อบังคับใช้ Referential Integrity ฉันจะใช้สิ่งต่อไปนี้: tablename_fk_columnname(เช่นการยกตัวอย่างที่ 3 เพิ่มเติมfoo_bar_foo_id) เนื่องจากนี่เป็นการรวมชื่อตาราง / ชื่อคอลัมน์จึงรับประกันได้ว่าจะไม่ซ้ำกันภายในฐานข้อมูล
ฉันเรียงลำดับคอลัมน์เช่นนี้: PKs, FKs และคอลัมน์อื่น ๆ ตามลำดับตัวอักษร

มีวิธีที่ดีกว่าและเป็นมาตรฐานมากกว่านี้หรือไม่?

mysql naming-conventions mysql-workbench

6

ผิดที่จะใช้สำหรับการเพิ่มอัตโนมัติ PK เพียงแค่ "id"? ทำไม? ชื่อของคอลัมน์มีความหมายเฉพาะในบริบทของตาราง ดังนั้นฉันมี "id" หนึ่งตัวในทุกตารางและอาจมี id_ <table_name> จำนวนมากสำหรับ FK

— Zbyszek

3

@Zbyszek ฉันคิดว่าเหตุผลที่ง่ายที่สุดในการต่อต้านนั้นเป็นเพียงเพื่อความมั่นคง แทนที่จะมีid_tableB=> โอ้ไม่มี คอลัมน์ที่มีชื่อแตกต่างกัน idความสอดคล้องของid_tableB=> id_tableBเพียงแค่ดู neater ... หรืออย่างที่ OP ทำ: foo_id=> foo_idแทนที่จะfoo_id=>id

— Don Cheadle

106

ฉันจะบอกว่าสิ่งแรกและสำคัญที่สุด: ให้สอดคล้องกัน

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

คะแนน 1 และ 2 เป็นสิ่งที่ดีที่ฉันคิด

จุดที่ 3 - น่าเศร้าที่ไม่สามารถทำได้ คิดเกี่ยวกับวิธีที่คุณจะรับมือกับตารางเดียวfoo_barที่มีคอลัมน์foo_idและanother_foo_idทั้งที่อ้างอิงfooตารางfoo_idคอลัมน์ คุณอาจต้องการพิจารณาวิธีจัดการกับสิ่งนี้ นี่เป็นกรณีมุมเล็กน้อย!

จุดที่ 4 - คล้ายกับจุดที่ 3 คุณอาจต้องการแนะนำหมายเลขที่ท้ายชื่อคีย์ต่างประเทศเพื่อรองรับการมีคอลัมน์อ้างอิงมากกว่าหนึ่งคอลัมน์

จุดที่ 5 - ฉันจะหลีกเลี่ยงสิ่งนี้ มันช่วยให้คุณมีน้อยและจะกลายเป็นปวดหัวเมื่อคุณต้องการเพิ่มหรือลบคอลัมน์จากตารางในภายหลัง

ประเด็นอื่น ๆ คือ:

อนุสัญญาการตั้งชื่อดัชนี

คุณอาจต้องการแนะนำแบบแผนการตั้งชื่อสำหรับดัชนี - นี่จะเป็นความช่วยเหลือที่ยอดเยี่ยมสำหรับงานเมทาดาทาฐานข้อมูลใด ๆ ที่คุณอาจต้องการดำเนินการ ตัวอย่างเช่นคุณอาจต้องการเรียกดัชนีfoo_bar_idx1หรือfoo_idx1- ทั้งหมดขึ้นอยู่กับคุณ แต่ควรพิจารณา

เอกพจน์ vs ชื่อพหูพจน์คอลัมน์

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

สิ่งสำคัญที่นี่แน่นอนแน่นอน!

— Tom Mac
แหล่งที่มา

อะไรจะดีไปกว่าจุดที่ 5 ทำไมมันถึงปวดหัว?

— Rasshu

7

ในการติดตามฉันพบว่า verry นี้มีประโยชน์สำหรับผู้ที่จะมาที่นี่ในภายหลัง: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/

— Enissay

1

ฉันมีปัญหาในการหา "รูปแบบ" ที่ดีสำหรับการตั้งชื่อตารางของฉันซึ่งเก็บวัตถุของแบบจำลองที่ประกอบด้วยสองชื่อ (DocumentChapter, DocumentVersion, DocumentType ฯลฯ ) ตัวอย่างเช่นสำหรับ DocumentType ฉันสามารถตั้งชื่อหรือdocumenttype document_typeฉันชอบหลังหนึ่ง document_document_typeแต่เวลาส่วนใหญ่ของฉันมีจำนวนมากเพื่อความสัมพันธ์จำนวนมากและฉันต้องการตารางมองเช่น ข้อเสนอแนะวิธีการจัดการนี้

— lexith

@ rsb2097 Re: จุด 5 - หลังจากเพิ่มหนึ่งคอลัมน์ (ไปยังจุดสิ้นสุด) คำสั่งซื้ออาจไม่ถูกต้อง คุณไม่ควรเพิ่มข้อ จำกัด ใด ๆ ที่ต้องสั่งซื้อคอลัมน์อีกครั้งเนื่องจากเป็นค่าใช้จ่ายที่ไม่จำเป็น

— จะ Sheppard

21

ความสอดคล้องเป็นกุญแจสำคัญในมาตรฐานการตั้งชื่อใด ๆ ตราบใดที่มันสมเหตุสมผลและสอดคล้องกันคุณจะอยู่ที่นั่น 99%

มาตรฐานเป็นความชอบส่วนบุคคลมาก - ดังนั้นหากคุณชอบมาตรฐานของคุณก็ให้รันด้วย

เพื่อตอบคำถามของคุณทันที - ไม่ MySQL ไม่มีแบบแผนการตั้งชื่อ / มาตรฐานที่ต้องการดังนั้นการม้วนตัวเองเป็นเรื่องปกติ

— mal-wan
แหล่งที่มา

8

MySQL มีคำอธิบายสั้น ๆ เกี่ยวกับกฎที่เข้มงวดมากขึ้นหรือน้อยลง:

https://dev.mysql.com/doc/internals/en/coding-style.html

สไตล์การเข้ารหัสที่พบมากที่สุดสำหรับ MySQL โดย Simon Holywell:

http://www.sqlstyle.guide/

ดูคำถามนี้ด้วย: มีแนวทางการเขียนโค้ดสำหรับ SQL ที่เผยแพร่หรือไม่?

— Daniel W.
แหล่งที่มา

4

โชคดีที่ผู้พัฒนา PHP ไม่ใช่ "Camel case bigots case" เหมือนกับชุมชนการพัฒนาที่ฉันรู้จัก

การประชุมของคุณฟังดูดี

ตราบใดที่มันเป็น a) ง่ายและ b) สอดคล้องกัน - ฉันไม่เห็นปัญหาใด ๆ :)

PS: โดยส่วนตัวแล้วฉันคิดว่า 5) เกินกำลัง ...

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

2

ห่างจากการเป็นใหญ่กรณีอูฐเป็นจริงขมวดคิ้วโดยชุมชน DB หลายเพราะ RDBMS บางส่วน 'เป็นกรณีตายไปจนถึงจุดที่พวกเขาจะตัดกรณี (หรือเปลี่ยนทุกอย่างเพื่อกรณีบน) ดังนั้นสิ่งที่น่าเกลียดจริง ๆ อย่างรวดเร็ว

— mal-wan

@mwan: คุณสามารถระบุ RDBMS ใดได้บ้าง และฉันก็เป็นจ๊อกกี้ตัวอูฐด้วยตัวเอง Caps ให้บริการเพียงวัตถุประสงค์เดียวใน schema ของฉันเพื่อระบุตารางการเข้าร่วมและ (ในกรณีของเขตข้อมูล) เพื่อระบุขอบเขตของคำดังนั้น _ อาจจะเป็นการเฉพาะเพื่อระบุ Othertable_id (เช่นชื่อตาราง = Othertable และเขตข้อมูลในตาราง = id ) นอกจากนี้หาก RDBMS อื่น ๆ ไม่คำนึงถึงขนาดตัวพิมพ์มันจะมีความสำคัญอะไร? ฉันจะไม่มีวันเปิดเผยเวอร์ชั่นเดียวกันและเวอร์ชั่นเล็กของตารางเดียวกัน! โอ้และฉันไม่ต้องการ RDBMS ที่ไม่ต้องตรงตามตัวพิมพ์ใหญ่ - ฉันควรเขียนรหัสที่สอดคล้องกัน

— Samuel Fullman

7

ฉันชอบประชดของผู้ใช้ MySQL ที่ไม่ชอบ CamelCase และชื่อของผลิตภัณฑ์ที่เราใช้: MySQL เขียนใน CamelCase

— DBX12

1

@ DBX12 การพูดคล่องนั่นคือ PascalCase ไม่ใช่ camelCase แต่จุดของคุณยังคงอยู่

— MarredCheese

@ MarredCheese ไม่เคยคิดเกี่ยวกับมัน แต่คุณพูดถูก camelCase ไม่ควรมีโคกตอนเริ่มต้น

— DBX12

1

คำตอบง่ายๆ:ไม่

อย่างน้อยก็มีหลักการตั้งชื่อที่ Oracle หรือชุมชนได้รับการสนับสนุนอย่างไรก็ตามโดยทั่วไปคุณต้องระวังการปฏิบัติตามกฎและข้อ จำกัด สำหรับตัวระบุเช่นที่ระบุในเอกสาร MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

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

จากประสบการณ์ส่วนตัวฉันจะแนะนำสิ่งนี้:

ใช้กรณีที่ต่ำกว่า วิธีนี้จะช่วยให้มั่นใจได้ถึงการทำงานร่วมกันเมื่อคุณโอนย้ายฐานข้อมูลของคุณจากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่น บางครั้งการlower_case_table_namesกำหนดค่าไม่ถูกต้องและเซิร์ฟเวอร์ของคุณเริ่มโยนข้อผิดพลาดเพียงแค่ไม่รู้จัก camelCase หรือ PascalCase มาตรฐานของคุณ (ปัญหาความไวของตัวพิมพ์เล็กและตัวพิมพ์ใหญ่)
ชื่อที่สั้น ง่ายและชัดเจน ที่ง่ายและรวดเร็วที่สุดคือการระบุตารางหรือคอลัมน์ของคุณที่ดีกว่า เชื่อใจฉันเมื่อคุณทำแบบสอบถามที่แตกต่างกันจำนวนมากในระยะเวลาอันสั้นจะดีกว่าที่จะมีทั้งหมดง่ายต่อการเขียน (และอ่าน)
คำนำหน้าหลีกเลี่ยง หากคุณไม่ได้ใช้ฐานข้อมูลเดียวกันสำหรับตารางของแอปพลิเคชันที่แตกต่างกันอย่าใช้ส่วนนำหน้า สิ่งนี้จะเพิ่มความฟุ่มเฟื่อยให้กับแบบสอบถามของคุณ มีบางสถานการณ์ที่สิ่งนี้มีประโยชน์ตัวอย่างเช่นเมื่อคุณต้องการระบุคีย์หลักและคีย์ต่างประเทศซึ่งโดยปกติจะใช้ชื่อตารางเป็นคำนำหน้าสำหรับคอลัมน์ id
ใช้เครื่องหมายขีดล่างสำหรับการแยกคำ หากคุณยังต้องการใช้มากกว่าหนึ่งคำสำหรับการตั้งชื่อตารางคอลัมน์ ฯลฯ ดังนั้นให้ใช้เครื่องหมายขีดล่างเพื่อแยก _the_wordsสิ่งนี้จะช่วยให้อ่านได้ชัดเจน (ดวงตาและสมองที่ตรึงเครียดของคุณกำลังจะขอบคุณ)
ให้สอดคล้อง เมื่อคุณมีมาตรฐานของคุณเองให้ปฏิบัติตาม อย่าเป็นคนที่สร้างกฎและเป็นคนแรกที่ทำลายสิ่งเหล่านี้นั่นเป็นสิ่งที่น่าละอาย

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

— ฟาบริซิโอบาเลนเซีย
แหล่งที่มา