ฉันเริ่มโครงการใหม่และต้องการรับชื่อตารางและคอลัมน์ของฉันตั้งแต่เริ่มต้น ตัวอย่างเช่นฉันเคยใช้พหูพจน์ในชื่อตารางเสมอ

ดังนั้นถ้าฉันได้รับตาราง "ผู้ใช้" แล้วฉันได้รับผลิตภัณฑ์ที่มีผู้ใช้เท่านั้นที่จะมีตารางควรมีชื่อ "user_product" หรือเพียงแค่ "ผลิตภัณฑ์"? นี่คือความสัมพันธ์แบบหนึ่งต่อหลาย

และถ้าหากฉันมีคำอธิบายผลิตภัณฑ์หลายอย่างสำหรับแต่ละผลิตภัณฑ์มันจะเป็น "user_product_description" หรือ "product_description" หรือเพียงแค่ "คำอธิบาย" หรือไม่ แน่นอนว่ามีการตั้งค่าคีย์ต่างประเทศที่เหมาะสม .. การตั้งชื่อเฉพาะคำอธิบายจะเป็นปัญหาเนื่องจากฉันอาจมีรายละเอียดผู้ใช้หรือรายละเอียดบัญชีหรืออะไรก็ตาม ..

ถ้าฉันต้องการตารางสัมพันธ์ที่บริสุทธิ์ (มากไปหามาก) ที่มีเพียงสองคอลัมน์สิ่งนี้จะมีลักษณะอย่างไร "user_stuff" หรืออาจจะเป็น "rel_user_stuff" และถ้าเป็นอันแรกสิ่งที่จะแยกความแตกต่างนี้จากตัวอย่างเช่น "user_product"?

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

ขอบคุณ

ตาราง•ชื่อ

เอกพจน์ที่เพิ่งเรียนรู้นั้นถูกต้อง

ใช่. ระวังพวกนอกศาสนา พหูพจน์ในชื่อตารางเป็นสัญญาณที่แน่นอนของคนที่ไม่ได้อ่านวัสดุมาตรฐานและไม่มีความรู้เกี่ยวกับทฤษฎีฐานข้อมูล

สิ่งมหัศจรรย์บางอย่างเกี่ยวกับมาตรฐาน ได้แก่ :

• พวกเขาทั้งหมดรวมเข้าด้วยกัน
• พวกเขาทำงานร่วมกัน
• พวกเขาเขียนด้วยใจที่ยิ่งใหญ่กว่าของเราดังนั้นเราจึงไม่ต้องถกเถียงพวกเขา

ชื่อตารางมาตรฐานหมายถึงแต่ละแถวในตารางซึ่งใช้ในการใช้คำฟุ่มเฟือยทั้งหมดไม่ใช่เนื้อหาทั้งหมดของตาราง (เรารู้ว่าCustomerตารางมีลูกค้าทั้งหมด)

ความสัมพันธ์, กริยาวลี

ในฐานข้อมูลเชิงสัมพันธ์ของแท้ที่ได้รับการสร้างแบบจำลอง (ซึ่งต่างจากระบบจัดเก็บข้อมูลในยุคก่อนปี 1970 [มีลักษณะRecord IDsซึ่งถูกนำไปใช้ในคอนเทนเนอร์ฐานข้อมูล SQL เพื่อความสะดวก):

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

Diagram_A

แน่นอนว่าความสัมพันธ์นั้นถูกนำมาใช้ใน SQL เช่นเดียวกับCONSTRAINT FOREIGN KEYในตารางลูก (เพิ่มเติมภายหลัง) นี่คือคำกริยาวลี (ในรูปแบบ) ที่สรุปว่ามันหมายถึง (อ่านจากแบบจำลอง) และ FK ชื่อ จำกัด :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

ตาราง•ภาษา

อย่างไรก็ตามเมื่ออธิบายตารางโดยเฉพาะอย่างยิ่งในภาษาทางเทคนิคเช่นภาคแสดงหรือเอกสารอื่น ๆ ให้ใช้เอกพจน์และพหูพจน์ตามปกติในภาษาอังกฤษ โปรดทราบว่าตารางนั้นมีชื่อสำหรับแถวเดี่ยว (ความสัมพันธ์) และภาษาหมายถึงแต่ละแถวที่ได้รับ (ความสัมพันธ์ที่ได้รับ):

    Each Customer initiates zero-to-many SalesOrders

ไม่

    Customers have zero-to-many SalesOrders 

ดังนั้นถ้าฉันมีตาราง "ผู้ใช้" แล้วฉันได้รับผลิตภัณฑ์ที่มีผู้ใช้เท่านั้นที่จะมีตารางควรมีชื่อ "ผู้ใช้ผลิตภัณฑ์" หรือเพียงแค่ "ผลิตภัณฑ์"? นี่คือความสัมพันธ์แบบหนึ่งต่อหลาย

(นั่นไม่ใช่คำถามแบบแผนการตั้งชื่อ; นั่นคือคำถามการออกแบบฐานข้อมูล aa) มันไม่สำคัญว่าuser::productจะเป็น 1 :: n สิ่งที่สำคัญคือไม่ว่าproductจะเป็นกิจการที่แยกต่างหากและไม่ว่าจะเป็นตารางอิสระเช่น มันสามารถอยู่ได้ด้วยตัวเอง ดังนั้นไม่ productuser_product

และถ้าproductมีอยู่เฉพาะในบริบทของการuserคือ มันเป็นตารางที่ขึ้นอยู่user_productดังนั้น

Diagram_B

และถ้าหากฉันมีคำอธิบายผลิตภัณฑ์หลายอย่างสำหรับแต่ละผลิตภัณฑ์มันจะเป็น "คำอธิบายผู้ใช้ผลิตภัณฑ์" หรือ "คำอธิบายผลิตภัณฑ์" หรือเพียงแค่ "คำอธิบาย" หรือไม่ แน่นอนว่ามีการตั้งค่าคีย์ต่างประเทศที่เหมาะสม .. การตั้งชื่อเฉพาะคำอธิบายจะเป็นปัญหาเนื่องจากฉันอาจมีรายละเอียดผู้ใช้หรือรายละเอียดบัญชีหรืออะไรก็ตาม

ถูกตัอง. ทั้งuser_product_descriptionxor product_descriptionจะถูกต้องตามข้างต้น มันไม่ได้แยกความแตกต่างจากที่อื่นxxxx_descriptionsแต่มันจะให้ความรู้สึกของชื่อที่มันเป็นคำนำหน้าเป็นตารางแม่

ถ้าฉันต้องการตารางสัมพันธ์ที่บริสุทธิ์ (มากไปหามาก) ที่มีเพียงสองคอลัมน์สิ่งนี้จะมีลักษณะอย่างไร "user-stuff" หรืออาจจะเป็น "rel-user-stuff"? และถ้าเป็นคนแรกสิ่งที่จะแยกความแตกต่างนี้จากตัวอย่างเช่น "ผู้ใช้ผลิตภัณฑ์"?

1. หวังว่าตารางทั้งหมดในฐานข้อมูลเชิงสัมพันธ์เป็นตารางเชิงสัมพันธ์ล้วนๆ ไม่จำเป็นต้องระบุว่าในชื่อ (มิฉะนั้นตารางทั้งหมดจะเป็นrel_something)

2. ถ้ามันมีเพียง PKs ของทั้งสองผู้ปกครอง (ซึ่งจะแก้ไขความสัมพันธ์เชิงตรรกะ n :: n ที่ไม่ได้อยู่เป็นนิติบุคคลในระดับตรรกะลงในตารางทางกายภาพ ) นั่นคือตารางที่เกี่ยวข้อง ใช่โดยทั่วไปชื่อคือการรวมกันของชื่อตารางหลักสองรายการ

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

     Diagram_C

   • หากไม่ใช่ตารางที่เกี่ยวข้อง (เช่น. นอกเหนือจากสอง PKs นั้นมีข้อมูล) จากนั้นตั้งชื่ออย่างเหมาะสมและวลีกริยาใช้กับมันไม่ใช่ผู้ปกครองในตอนท้ายของความสัมพันธ์

     Diagram_D

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

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

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

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

1. Caseเป็นรายการแรกที่ระบุ ตัวพิมพ์ใหญ่ทั้งหมดไม่สามารถยอมรับได้ กรณีผสมเป็นเรื่องปกติโดยเฉพาะถ้าผู้ใช้สามารถเข้าถึงตารางได้โดยตรง อ้างอิงโมเดลข้อมูลของฉัน โปรดทราบว่าเมื่อผู้ค้นหาใช้ NonSQL ที่มีการเสื่อมซึ่งมีตัวพิมพ์เล็กเท่านั้นฉันให้สิ่งนั้นซึ่งในกรณีนี้ฉันรวมเครื่องหมายขีดล่าง (ตามตัวอย่างของคุณ)

2. รักษาโฟกัสข้อมูลไม่ใช่แอปพลิเคชันหรือโฟกัสการใช้งาน หลังจาก 2011 เรามีOpen Architectureมาตั้งแต่ปี 1984 และฐานข้อมูลควรจะเป็นอิสระจากแอพที่ใช้พวกเขา

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

3. มีน้ำใจมากและตารางชื่อและคอลัมน์มากได้อย่างถูกต้อง อย่าใช้UpdatedDateถ้ามันเป็นประเภทข้อมูลการใช้งานDATETIME UpdatedDtmอย่าใช้_descriptionถ้ามันมีปริมาณ

4. มันเป็นสิ่งสำคัญที่จะสอดคล้องกันในฐานข้อมูล ห้ามใช้NumProductในสถานที่เดียวเพื่อระบุจำนวนผลิตภัณฑ์และItemNoหรือItemNumในสถานที่อื่นเพื่อระบุจำนวนรายการ ใช้NumSomethingตัวเลขและSomethingNoหรือSomethingIdสำหรับตัวระบุอย่างสม่ำเสมอ

5. อย่าคำนำหน้าชื่อคอลัมน์ที่มีชื่อตารางหรือรหัสพิเศษสั้น ๆ user_first_nameเช่น SQL จัดเตรียมไว้สำหรับ tablename เป็น qualifier แล้ว:

       table_name.column_name  -- notice the dot
   

6. ข้อยกเว้น

   • ข้อยกเว้นแรกคือสำหรับ PKs พวกเขาต้องการการจัดการพิเศษเพราะคุณรหัสพวกเขาในการเข้าร่วมตลอดเวลาและคุณต้องการให้ปุ่มโดดเด่นจากคอลัมน์ข้อมูล มักจะใช้ไม่เคยuser_idid

     • โปรดทราบว่านี่ไม่ใช่ชื่อตารางที่ใช้เป็นคำนำหน้า แต่เป็นชื่อที่เหมาะสมสำหรับส่วนประกอบของคีย์: user_idเป็นคอลัมน์ที่ระบุผู้ใช้ไม่ใช่idของuserตาราง
       • (ยกเว้นหลักสูตรในระบบการจัดเก็บบันทึกที่ไฟล์ถูกเข้าถึงโดยตัวแทนและไม่มีกุญแจที่เกี่ยวข้องมีพวกเขาเป็นหนึ่งและสิ่งเดียวกัน)
     • ใช้ชื่อเดียวกันที่แน่นอนสำหรับคอลัมน์คีย์ทุกครั้งที่มีการใช้ PK (ย้ายข้อมูล) เป็น FK
     • ดังนั้นuser_productตารางจะมีuser_idเป็นส่วนประกอบของ (user_id, product_no)PK
     • ความเกี่ยวข้องของสิ่งนี้จะชัดเจนเมื่อคุณเริ่มการเข้ารหัส ก่อนอื่นด้วยidหลาย ๆ ตารางมันจะง่ายขึ้นในการเขียนโปรแกรม SQL ประการที่สองใคร ๆ ที่ coder เริ่มต้นไม่รู้ว่าเขากำลังพยายามทำอะไร ทั้งสองอย่างนี้ง่ายต่อการป้องกันหากคอลัมน์สำคัญได้รับการปฏิบัติดังกล่าวข้างต้น

   • ข้อยกเว้นที่สองคือที่ที่มีมากกว่าหนึ่ง FK อ้างอิงตารางหลักตารางเดียวกันดำเนินการในเด็ก ตามแบบจำลองเชิงสัมพันธ์ใช้ชื่อบทบาทเพื่อแยกความหมายหรือการใช้งานเช่น AssemblyCodeและสองComponentCode PartCodesและในกรณีที่ไม่ได้ใช้งานแตกต่างPartCodeหนึ่งของพวกเขา มีความแม่นยำ

     Diagram_E

7. คำนำหน้าใน
   กรณีที่คุณมีมากกว่า 100 ตารางให้นำหน้าชื่อตารางด้วยหัวเรื่อง:

   REF_ สำหรับตารางอ้างอิง
   OE_สำหรับกลุ่มรายการสั่งซื้อ ฯลฯ

   เฉพาะในระดับกายภาพเท่านั้นไม่ใช่แบบลอจิคัล (มันจะตัดโมเดล)

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

   _Vมุมมอง (ที่มีตัวTableNameหน้าหลักแน่นอน)
   _fkForeign Key (ชื่อข้อ จำกัด ไม่ใช่ชื่อคอลัมน์) การแบ่งส่วน
   _cacแคช(proc หรือฟังก์ชันที่เก็บไว้) ฟังก์ชัน (ไม่ใช่ธุรกรรม) ฯลฯ
   _seg
_tr
_fn

   รูปแบบคือชื่อตารางหรือ FK, เครื่องหมายขีดล่างและชื่อการกระทำขีดเส้นใต้และท้ายที่สุดท้าย

   สิ่งนี้สำคัญมากเพราะเมื่อเซิร์ฟเวอร์แจ้งข้อผิดพลาด:

   ____blah blah blah error on object_name

   คุณรู้แน่ชัดว่ามีวัตถุใดถูกละเมิดและสิ่งที่พยายามทำ:

   ____blah blah blah error on Customer_Add_tr

9. Foreign Keys (ข้อ จำกัด ไม่ใช่คอลัมน์) การตั้งชื่อที่ดีที่สุดสำหรับ FK คือการใช้คำกริยาวลี (ลบด้วย "แต่ละ" และ cardinality)

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   ใช้Parent_Child_fkลำดับไม่ใช่Child_Parent_fkเพราะ (a) มันแสดงขึ้นในลำดับการเรียงที่ถูกต้องเมื่อคุณกำลังมองหาพวกเขาและ (b) เรามักรู้จักเด็ก ๆ ที่เกี่ยวข้องสิ่งที่เราคาดเดาคือผู้ปกครองคนใด ข้อความแสดงข้อผิดพลาดนั้นน่ายินดี

   Foreign key violation on Vendor_Offers_PartVendor_fk____

   ซึ่งทำงานได้ดีสำหรับผู้ที่ต้องการสร้างแบบจำลองข้อมูลของพวกเขาซึ่งมีการระบุวลีคำกริยา สำหรับส่วนที่เหลือระบบการจัดเก็บบันทึก ฯลฯ Parent_Child_fkการใช้งาน

10. ดัชนีมีความพิเศษดังนั้นพวกเขาจึงมีการตั้งชื่อแบบแผนของตัวเองสร้างขึ้นตามลำดับตัวละครแต่ละตำแหน่งจาก 1 ถึง 3:

    Uไม่ซ้ำหรือ_สำหรับที่ไม่ซ้ำกัน
    Cคลัสเตอร์หรือ_สำหรับ
    _ตัวคั่นที่ ไม่ใช่คลัสเตอร์

    สำหรับส่วนที่เหลือ:

    • ถ้าคีย์คือหนึ่งคอลัมน์หรือคอลัมน์น้อยมาก:
      ____ColumnNames

    • หากคีย์มากกว่าสองสามคอลัมน์:
      ____ PKคีย์หลัก (ตามรุ่น)
      ____ AK[*n*]คีย์สำรอง (คำศัพท์ IDEF1X)

    โปรดทราบว่าไม่จำเป็นต้องใช้ชื่อตารางในชื่อดัชนีเนื่องจากจะแสดงเป็นเสมอtable_name.index_name.

    ดังนั้นเมื่อCustomer.UC_CustomerIdหรือProduct.U__AKปรากฏในข้อความแสดงข้อผิดพลาดมันจะบอกบางสิ่งที่มีความหมาย เมื่อคุณดูดัชนีบนโต๊ะคุณสามารถแยกความแตกต่างได้อย่างง่ายดาย

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

    • พวกเขามีตัวอย่างจริงของทั้งหมดข้างต้น ถามคำถามเกี่ยวกับการตั้งชื่อคำถามในหัวข้อนี้
    • แน่นอนว่ารูปแบบการใช้มาตรฐานอื่น ๆ อีกหลายนอกเหนือจากการตั้งชื่อการประชุม; คุณสามารถเพิกเฉยได้ตอนนี้หรืออย่าลังเลที่จะถามคำถามใหม่ๆ
    • แต่ละหน้ามีหลายหน้าสนับสนุนรูปภาพแบบอินไลน์ที่ Stack Overflow ใช้สำหรับนกและไม่โหลดอย่างสม่ำเสมอบนเบราว์เซอร์ที่แตกต่างกัน ดังนั้นคุณจะต้องคลิกลิงก์
    • โปรดทราบว่าไฟล์ PDF มีการนำทางแบบสมบูรณ์ดังนั้นให้คลิกที่ปุ่มแก้วสีน้ำเงินหรือวัตถุที่ระบุส่วนขยาย:
    • ผู้อ่านที่ไม่คุ้นเคยกับมาตรฐานการสร้างแบบจำลองเชิงสัมพันธ์อาจพบว่าสัญกรณ์ IDEF1X มีประโยชน์

รายการสั่งซื้อและสินค้าคงคลังพร้อมที่อยู่ที่เป็นไปตามมาตรฐาน

ระบบBulletinระหว่างสำนักงานง่าย ๆสำหรับ PHP / MyNonSQL

การตรวจสอบเซ็นเซอร์ด้วยความสามารถชั่วคราว

คำตอบสำหรับคำถาม

^{ที่ไม่สามารถตอบได้อย่างสมเหตุสมผลในพื้นที่ความคิดเห็น}

Larry Lustig:
... แม้ตัวอย่างที่น่ารำคาญที่สุดก็แสดงให้เห็น ...
หากลูกค้ามีผลิตภัณฑ์ที่มีค่าเป็นศูนย์และผลิตภัณฑ์มีส่วนประกอบแบบหนึ่งต่อหลายและส่วนประกอบมีซัพพลายเออร์แบบหนึ่งต่อหลายและซัพพลายเออร์ขายเป็นศูนย์ - to-many Components และ SalesRep มีลูกค้าแบบหนึ่งต่อหลายคน "ธรรมชาติ" ตั้งชื่อตารางว่าลูกค้าลูกค้าผลิตภัณฑ์ส่วนประกอบและซัพพลายเออร์อย่างไร

ความคิดเห็นของคุณมีปัญหาสำคัญสองประการ:

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

2. การเก็งกำไร "เล็กน้อย" นั้นมีข้อผิดพลาดขั้นต้นหลายประการ (การออกแบบฐานข้อมูล)

   • จนกว่าคุณจะแก้ไขสิ่งเหล่านั้นพวกเขาจะผิดธรรมชาติและผิดปกติและพวกเขาก็ไม่ได้มีเหตุผลใด ๆ คุณอาจตั้งชื่อพวกเขาว่าเป็นสิ่งผิดปกติเช่น _2, ผิดปกติ _2 และอื่น ๆ

   • คุณมี "ผู้จัดหา" ที่ไม่ได้จัดหาอะไร การอ้างอิงแบบวงกลม (ผิดกฎหมายและไม่จำเป็น); ลูกค้าที่ซื้อผลิตภัณฑ์ที่ไม่มีเครื่องมือทางการค้า (เช่นใบแจ้งหนี้หรือคำสั่งขาย) เป็นพื้นฐานสำหรับการซื้อ (หรือทำผลิตภัณฑ์ "เจ้าของ" ของลูกค้าหรือไม่); ความสัมพันธ์แบบกลุ่มต่อกลุ่ม เป็นต้น

   • ทันทีที่ได้รับการทำให้เป็นมาตรฐานและระบุตารางที่ต้องการชื่อของพวกเขาจะกลายเป็นชัดเจน เป็นธรรมชาติ

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

• ฉันจะสมมติว่าหากผลิตภัณฑ์ประกอบด้วยส่วนประกอบจากนั้นผลิตภัณฑ์คือชุดประกอบและส่วนประกอบถูกใช้ในชุดประกอบมากกว่าหนึ่งชุด

• เพิ่มเติมเนื่องจาก "ซัพพลายเออร์ขายส่วนประกอบที่ไม่เป็นศูนย์" เพื่อที่พวกเขาจะไม่ขายผลิตภัณฑ์หรือชุดประกอบพวกเขาจึงขายเฉพาะส่วนประกอบ

การเก็งกำไรเทียบกับรูปแบบปกติ

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

... ชื่อ "ธรรมชาติ" คือชื่อของตารางที่มีลูกค้าผลิตภัณฑ์ส่วนประกอบและซัพพลายเออร์

• ลูกค้า
• สินค้า
• ส่วนประกอบ (หรือ AssemblyComponent สำหรับผู้ที่ตระหนักว่าข้อเท็จจริงหนึ่งระบุอีกอัน)
• ผู้ผลิต

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

VoteCoffee:
คุณจัดการสถานการณ์จำลอง Ronnis อย่างไรในตัวอย่างของเขาที่มีความสัมพันธ์หลายอย่างระหว่าง 2 ตาราง (user_likes_product, user_bought_product)? ฉันอาจเข้าใจผิด แต่สิ่งนี้ดูเหมือนจะส่งผลให้ชื่อตารางซ้ำโดยใช้แบบแผนที่คุณระบุรายละเอียด

สมมติว่าไม่มีข้อผิดพลาดการทำให้เป็นมาตรฐานUser likes Productเป็นเพรดิเคตไม่ใช่ตาราง อย่าสับสนพวกเขา อ้างถึงคำตอบของฉันที่เกี่ยวข้องกับหัวเรื่องคำกริยาและภาคแสดงและคำตอบของฉันที่มีต่อ Larry ทันทีด้านบน

• แต่ละตารางมีชุดของข้อเท็จจริง (แต่ละแถวคือข้อเท็จจริง) เพรดิเคต (หรือข้อเสนอ) ไม่ใช่ข้อเท็จจริงพวกเขาอาจจะจริงหรือไม่ก็ได้

  • สัมพันธ์รุ่นจะขึ้นอยู่กับการสั่งซื้อครั้งแรกแคลคูลัส (ที่รู้จักกันทั่วไปว่าเป็นลอจิกการสั่งซื้อครั้งแรก) ภาคแสดงเป็นประโยคประโยคเดียวในภาษาอังกฤษที่เรียบง่ายและแม่นยำซึ่งประเมินว่าจริงหรือเท็จ

  • ยิ่งไปกว่านั้นแต่ละตารางแสดงให้เห็นหรือเป็นการนำไปใช้ของเพรดิเคตหลาย ๆอันไม่ใช่หนึ่ง

• แบบสอบถามคือการทดสอบของเพรดิเคต (หรือจำนวนเพรดิเคตที่ถูกล่ามโซ่ไว้ด้วยกัน) ซึ่งส่งผลให้เป็นจริง (ความจริงมีอยู่) หรือเท็จ (ความจริงไม่มีอยู่จริง)

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

• นี่ไม่ใช่ข้อเสนอแนะที่พวกเขาไม่สำคัญ พวกเขามีความสำคัญมาก แต่ฉันจะไม่เขียนมันที่นี่

• อย่างรวดเร็วแล้ว เนื่องจากRelational Modelถูกสร้างขึ้นบน FOPC ฐานข้อมูลทั้งหมดสามารถกล่าวได้ว่าเป็นชุดของการประกาศ FOPC ซึ่งเป็นชุดของเพรดิเคต แต่ (ก) มีหลายประเภทของ Predicates และ (ข) ตารางที่ไม่ได้เป็นตัวแทนหนึ่งคำกริยา (มันเป็นการดำเนินการทางกายภาพของหลาย Predicates และแตกต่างกันประเภทของ Predicates)

• ดังนั้นการตั้งชื่อตารางสำหรับ "" เพรดิเคตนั้น "หมายถึง" เป็นแนวคิดที่ไร้สาระ

• "นักทฤษฎี" ทราบเพียงไม่กี่ภาคส่วนพวกเขาไม่เข้าใจว่าเนื่องจากRMก่อตั้งขึ้นบน FOL ฐานข้อมูลทั้งหมดเป็นชุดของภาคแสดงและประเภทต่างๆ

  • และแน่นอนพวกเขาเลือกคนที่ไร้สาระจากไม่กี่คนที่พวกเขาไม่ทราบEXISTING_PERSON; PERSON_IS_CALLED. ถ้ามันไม่ได้เศร้ามันก็จะเฮฮา

  • โปรดทราบว่าชื่อตารางมาตรฐานหรืออะตอมมิก (การตั้งชื่อแถว) ทำงานได้อย่างยอดเยี่ยมสำหรับ verbiage ทั้งหมด (รวมถึงเพรดิเคตทั้งหมดที่แนบมากับตาราง) ในทางกลับกันชื่อ "ตารางแสดงถึงภาคแสดง" ไม่สามารถใช้ได้ ซึ่งเป็นสิ่งที่ดีสำหรับ "นักทฤษฎี" ที่เข้าใจน้อยมากเกี่ยวกับเพรดิเคต แต่ปัญญาอ่อน

• เพรดิเคตที่เกี่ยวข้องกับตัวแบบข้อมูลถูกแสดงในตัวแบบพวกมันเป็นสองออเดอร์

  1. เอกกริยา
     ชุดแรกเป็นแผนภาพไม่ข้อความ: สัญกรณ์ของตัวเอง เหล่านี้รวมถึง Existential ต่างๆ ข้อ จำกัด ที่มุ่งเน้น; และ Descriptor (แอ็ตทริบิวต์) เพรดิเคต

     • แน่นอนว่าหมายถึงเฉพาะผู้ที่สามารถ 'อ่าน' แบบจำลองข้อมูลมาตรฐานเท่านั้นที่สามารถอ่านภาคแสดงเหล่านั้นได้ ซึ่งเป็นเหตุผลที่ "นักทฤษฎี" ซึ่งพิการอย่างรุนแรงจากความคิดเฉพาะข้อความของพวกเขาไม่สามารถอ่านแบบจำลองข้อมูลได้ทำไมพวกเขาถึงติดกับความคิดข้อความอย่างเดียวก่อนปี 1984

  2. เพรดิเคตไบนารี
     ชุดที่สองคือความสัมพันธ์ระหว่างข้อเท็จจริง นี่คือสายสัมพันธ์ คำกริยาวลี (รายละเอียดด้านบน) ระบุภาคแสดงข้อเสนอที่นำไปใช้ (ซึ่งสามารถทดสอบได้ผ่านการสืบค้น) อย่างใดอย่างหนึ่งไม่สามารถรับเพิ่มเติมชัดเจนกว่านั้น

     • ดังนั้นสำหรับผู้ที่ชำนาญในโมเดลข้อมูลมาตรฐานเพรดิเคตทั้งหมดที่เกี่ยวข้องมีการบันทึกไว้ในโมเดล พวกเขาไม่ต้องการรายการเพรดิเคตที่แยกต่างหาก (แต่ผู้ใช้ที่ไม่สามารถ 'อ่าน' ทุกอย่างจากตัวแบบข้อมูลทำได้!)

• นี่คือตัวแบบข้อมูลที่ฉันแสดงรายการภาคแสดง ฉันเลือกตัวอย่างนั้นเพราะมันแสดง Existential, ฯลฯ , เพรดิเคต, รวมถึงความสัมพันธ์, เพรดิเคตเดียวที่ไม่อยู่ในรายการคือ Descriptors ที่นี่เนื่องจากระดับการเรียนรู้ของผู้แสวงหาฉันกำลังปฏิบัติต่อเขาในฐานะผู้ใช้

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

กฎที่ฉันให้สำหรับวลีคำกริยาสำหรับชื่อความสัมพันธ์สำหรับตารางที่เกี่ยวข้องมาเล่นที่นี่ นี่คือการสนทนาเปรียบเทียบกับตารางซึ่งครอบคลุมทุกจุดที่กล่าวถึงโดยสรุป

สำหรับคำอธิบายสั้น ๆ ที่ดีอีกครั้งใช้ที่เหมาะสมของ Predicates และวิธีการใช้พวกเขา (ซึ่งค่อนข้างบริบทที่แตกต่างกับที่ของการตอบสนองต่อความคิดเห็นที่นี่) เยี่ยมชมคำตอบนี้และเลื่อนลงไปที่คำกริยาส่วน

Charles Burns:
ตามลำดับฉันหมายถึงออบเจ็กต์สไตล์ Oracle ที่ใช้เพื่อจัดเก็บตัวเลขและถัดไปตามกฎบางอย่าง (เช่น "เพิ่ม 1") เนื่องจาก Oracle ไม่มีตาราง auto-ID การใช้งานทั่วไปของฉันคือการสร้างรหัสเฉพาะสำหรับตาราง PK INSERT INTO foo (id, somedata) ค่า (foo_s.nextval, "data" ... )

ตกลงนั่นคือสิ่งที่เราเรียกว่าตาราง Key หรือ NextKey ตั้งชื่อมันเช่น ถ้าคุณมี SubjectAreas ให้ใช้ COM_NextKey เพื่อระบุว่าเป็นเรื่องธรรมดาในฐานข้อมูล

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

เอกพจน์กับพหูพจน์: เลือกหนึ่งและติดกับมัน

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

อย่าฝังข้อมูลประเภทในชื่อเช่น "vc_firstname" สำหรับ varchar หรือ "flavour_enum" อย่าฝังข้อ จำกัด ในชื่อคอลัมน์เช่น "department_fk" หรือ "employee_pk"

อันที่จริงสิ่งที่ดีเกี่ยวกับการแก้ไขเท่านั้น * ฉันสามารถคิดคือการที่คุณสามารถใช้คำสงวนเช่นwhere_t, tbl_order,user_vw ,แน่นอนในตัวอย่างเหล่านั้นการใช้พหูพจน์จะช่วยแก้ไขปัญหา :)

อย่าตั้งชื่อคีย์ทั้งหมด "ID" คีย์ที่อ้างถึงสิ่งเดียวกันควรมีชื่อเหมือนกันในตารางทั้งหมด คอลัมน์ ID ผู้ใช้อาจเรียกว่า USER_ID ในตารางผู้ใช้และตารางทั้งหมดที่อ้างอิงผู้ใช้ ครั้งเดียวที่มีการเปลี่ยนชื่อคือเมื่อผู้ใช้ที่แตกต่างกันกำลังเล่นบทบาทที่แตกต่างกันเช่นข้อความ (sender_user_id, receiver_user_id) สิ่งนี้จะช่วยได้มากเมื่อจัดการกับข้อความค้นหาที่ใหญ่ขึ้น

เกี่ยวกับ CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

โดยทั่วไปจะเป็นการดีกว่าถ้าตั้งชื่อ "ตารางการแมป" เพื่อให้ตรงกับความสัมพันธ์ที่อธิบายไว้แทนที่จะเป็นชื่อของตารางที่อ้างอิง ผู้ใช้สามารถมีจำนวนของความสัมพันธ์กับผลิตภัณฑ์ใด ๆuser_likes_product: user_bought_product, user_wants_to_buy_product,

ไม่มี 'ถูกต้อง' เกี่ยวกับเอกพจน์ vs พหูพจน์ - ส่วนใหญ่เป็นเรื่องของรสนิยม

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

1. เนื่องจากคุณอาจต้องใช้ 'ผู้ใช้' ของตาราง, อีก 'ผลิตภัณฑ์' และที่สามเพื่อเชื่อมต่อผู้ใช้กับผลิตภัณฑ์จากนั้นคุณต้องมีตาราง 'user_product'

2. เนื่องจากคำอธิบายนี้ใช้กับผลิตภัณฑ์คุณจะต้องใช้ 'product_description' ถ้าผู้ใช้แต่ละคนตั้งชื่อผลิตภัณฑ์แต่ละตัวไม่ได้ ...

3. ตาราง 'user_product' คือ (หรืออาจ) ตัวอย่างของตารางที่มี ID ผลิตภัณฑ์และ ID ผู้ใช้และไม่มากนัก คุณตั้งชื่อตารางสองแอตทริบิวต์ในลักษณะทั่วไปเดียวกัน: 'user_stuff' คำนำหน้าการตกแต่งเช่น 'rel_' ไม่ได้ช่วยอะไรจริงๆ คุณจะเห็นบางคนใช้ 't_' หน้าชื่อตารางแต่ละชื่อเช่น นั่นไม่ได้ช่วยอะไรมากมาย

พหูพจน์ไม่เลวตราบใดที่มีการใช้อย่างต่อเนื่อง แต่เอกพจน์คือความชอบของฉัน

ฉันจะแจกจ่ายด้วยการขีดเส้นใต้ถ้าคุณไม่ต้องการร่างความสัมพันธ์แบบหลายต่อหลายคน และใช้เงินทุนเริ่มต้นเพราะช่วยแยกแยะสิ่งต่าง ๆ ใน ORM

แต่มีการตั้งชื่อหลายแบบดังนั้นถ้าคุณต้องการใช้ขีดเส้นใต้นั่นก็โอเคตราบใดที่มันทำอย่างสม่ำเสมอ

ดังนั้น:

User

UserProduct (it is a users products after all)

หากผู้ใช้เพียงรายเดียวสามารถมีผลิตภัณฑ์ใด ๆ ได้

UserProductDescription

แต่ถ้าผู้ใช้แบ่งปันผลิตภัณฑ์:

ProductDescription

หากคุณบันทึกขีดล่างของคุณสำหรับความสัมพันธ์แบบกลุ่มต่อกลุ่มคุณสามารถทำสิ่งต่อไปนี้:

UserProduct_Stuff

เพื่อสร้าง M-to-M ระหว่าง UserProduct และ Stuff - ไม่แน่ใจจากคำถามถึงลักษณะที่แน่นอนของหลายต่อหลายคนที่ต้องการ

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

เกี่ยวกับคำถามของคุณหาก 'ผลิตภัณฑ์' และ 'คำอธิบายผลิตภัณฑ์' เป็นแนวคิดที่มีตัวตน (เช่นเอนทิตี) ในแบบจำลองของคุณฉันก็จะเรียกตาราง 'ผลิตภัณฑ์' และ 'คำอธิบายผลิตภัณฑ์' สำหรับตารางที่ใช้เพื่อสร้างความสัมพันธ์แบบหลายต่อกลุ่มฉันมักใช้หลักการตั้งชื่อ "SideA2SideB" เช่น "Student2Course"