ความสำคัญของแผนภาพ ER

ฉันเป็นนักเรียนและฉันกำลังพัฒนาหลายโครงการในฐานะส่วนหนึ่งของสถาบันการศึกษาของฉัน

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

คนส่วนใหญ่ชอบที่จะพัฒนาฐานข้อมูลแบบบินด้วยวาจาตามความต้องการของระบบบนกระดาษโดยตรง

ตอนนี้ฉันเป็นผู้ติดตามหลักการของฐานข้อมูลอย่างเข้มงวด ฉันคิดว่าฐานข้อมูลควรพัฒนาจาก ERD เท่านั้น ดังนั้นฉันต้องการรู้ดังต่อไปนี้:

• อุตสาหกรรมปฏิบัติตามหลักการเหล่านี้หรือไม่?
• ฉันเพิ่งเสียเวลาในการพัฒนา ERD หรือไม่?
• การพัฒนา ERD มีประโยชน์อย่างไร?

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

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

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

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

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

หากคุณเจอกับฐานข้อมูลไม่กี่ปีต่อมาหากไม่มี ERD คุณต้องใช้เวลามากมายในการดูว่าเกิดอะไรขึ้นในโครงการของคุณ

ฉันมี บริษัท และเราออกแบบ ERD ไม่เคยคิดเกี่ยวกับฐานข้อมูลโดยไม่มี ERD (อันที่จริงแล้วนี่คือการทดลองส่วนตัวของฉันเอง)

ERD เคยเป็นกระแสหลักมากขึ้นเมื่อไม่นานมานี้ IMO พวกเขาเป็นตัวเลือกมากขึ้นหรือน้อยลงในขณะนี้

ในปัจจุบันทีมที่ประสบความสำเร็จอย่างสูงบางคนไม่ได้ใส่ใจกับ ERD เลย แต่ยังมอบระบบที่ยอดเยี่ยม: แข็งแกร่งประสิทธิภาพและง่ายต่อการบำรุงรักษาในระยะยาว นี่คือความจริงโดยเฉพาะอย่างยิ่งในการพัฒนา Agile เมื่อเราเริ่มต้นเล็ก ๆ ด้วยชุดเครื่องมือที่เรียบง่าย

ERD เป็นวิธีการสื่อสารที่ดีแน่นอน แต่ไม่เคยมีวิธีเดียวหรือดีที่สุดในทุกสถานการณ์ บางทีมต้องการวิธีอื่น ๆ ในการจัดทำเอกสารและการสื่อสาร

ไม่มีกฎแบบครอบคลุมในอุตสาหกรรมนี้

สิ่งสำคัญคือการออกแบบก่อนที่จะเขียนรหัสการผลิต มันก็เป็นสิ่งสำคัญเช่นกันที่จะต้นแบบ; คนฐานข้อมูลพัฒนาต้นแบบโดยการเขียน SQL (จำสิ่งที่ Fred Brooks พูดเกี่ยวกับต้นแบบได้หรือไม่)

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

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

การสร้างแบบจำลองบทบาทวัตถุ (ORM)มีภาษากราฟิก แต่มันขึ้นอยู่กับ "ข้อเท็จจริง" (ประโยคง่าย ๆ ) นักธุรกิจสามารถตรวจสอบข้อเท็จจริงได้อย่างง่ายดาย นักธุรกิจไม่สามารถตรวจสอบไดอะแกรม ER หรือไดอะแกรม ORM ได้อย่างง่ายดาย