ชื่อตารางพหูพจน์กับเอกพจน์

ฉันจะตั้งชื่อตารางอย่างไรเมื่อสร้างฐานข้อมูลใหม่

Singular: Clientหรือพหูพจน์: Clients?

แล้วแต่คุณ. เพียง แต่ต้องสอดคล้องกัน

ส่วนตัวฉันชอบเอกพจน์ตามร้านค้าแต่ละแถว *: การสั่งซื้อสินค้าผู้ใช้รายการ ฯลฯ

สิ่งนี้ตรงกับการสร้างแบบจำลองของฉัน (ผ่านการจำลองบทบาทของวัตถุ) ที่ฉันใช้เอนทิตี / ประเภทเอกพจน์

แก้ไข:

เหตุผลหนึ่งคือพหูพจน์ล้มเหลวเมื่อคุณมีตารางการเชื่อมโยง:
Orders, Productsจะให้หรือOrderProducts OrdersProductsเสียงไม่ถูกต้อง

หรือตารางประวัติ (แน่นอนว่าคุณสามารถใช้สกีมาสำหรับสิ่งนี้):
Orders-> OrdersHistoryหรือ (ไม่!) OrdersHistories? จะไม่Order-> OrderHistoryดีกว่าไหม

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

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

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

ถ้าคุณต้องการระบุคอลเล็กชันในโปรแกรมคุณสามารถใช้พหูพจน์หรือดีกว่าใช้ตัวดัดแปลงที่เหมาะสมเช่น EmployeeList หรือ EmployeeArray

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

ภาษาอังกฤษไม่ใช่ภาษาการเขียนโปรแกรมที่ดีและเหมาะสมและการพยายามทำให้คำสั่งฐานข้อมูลและโปรแกรมสอดคล้องกับภาษาอังกฤษเพราะฟังดูดีกว่าที่จะอ่านหนึ่งในข้อความเหล่านั้นเป็นความผิดพลาด

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

ความชอบของฉันคือพหูพจน์ฟังดูดีกว่าในSELECTข้อความ:

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

ฉันหมายถึงในกรณีนี้อย่างน้อยมีหลายคนในตารางและหลายคนถูกส่งกลับไปยังลูกค้า

"คำสั่งซื้อ" เป็นคำสงวน "คำสั่งซื้อ" ไม่ใช่

"ผู้ใช้" เป็นคำที่สงวนไว้ "ผู้ใช้" ไม่ใช่

"เซสชั่น" เป็นคำที่สงวนไว้ "เซสชัน" ไม่ใช่

"result" เป็นคำที่สงวนไว้ "ผลลัพธ์" ไม่ใช่

"ญาติ" เป็นคำที่สงวนไว้ "ญาติ" ไม่ใช่

...

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

ฉันเชื่อว่าตาราง SQL ควรมีชื่อพหูพจน์ มันอ่านดีขึ้นมาก

ตารางของบันทึกหนังสือควรเรียกว่าหนังสือ ORM ควรใช้หลักการเดียวกัน วัตถุ Books เป็นคอลเล็กชันและควบคุมทุกระเบียนในตาราง Books วัตถุหนังสือเป็นประธานในระเบียนเดียว

ทำให้การเข้ารหัสเป็นธรรมชาติยิ่งขึ้น

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

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

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

เรามองสิ่งต่าง ๆ จากมุมมองที่แตกต่างกันและฉันคิดว่าค่ายทั้งสองนั้นมีการระบุโดย:

เอกพจน์ ("ผู้ใช้")
บุคคลที่สร้างความสัมพันธ์ระหว่างชื่อตารางและความจริงมันหมายถึงภาชนะซึ่งสามารถมีหลายแถว

ดังนั้น "คอนเทนเนอร์ของผู้ใช้" สามารถมีได้หลายแถว

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

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

ฉันคิดว่านี่เป็นเพราะหลายปีของพหูพจน์เป็นเรื่องธรรมดาและในสื่อการสอนออนไลน์ส่วนใหญ่

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

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

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