ทั้ง Doctrine และ Propel ใช้ประโยชน์จากการสืบทอดตารางแบบเดี่ยวและเป็นรูปธรรมในการทำแผนที่ความสัมพันธ์ของวัตถุ อดีตเห็นเขตข้อมูลที่เป็นไปได้ทั้งหมดในแผนผังชั้นที่แมปกับตารางเดียว - ในขณะที่หลังแมปแต่ละคลาสกับตารางที่เฉพาะเจาะจงการทำซ้ำเขตข้อมูลทั่วไปในลำดับชั้นการสืบทอด
ในขณะที่สิ่งนี้เอื้อต่อเครื่องมือ ORM มันแนะนำการออกแบบฐานข้อมูลที่ไม่ดีสำหรับฉัน รูปแบบการออกแบบที่ไม่ดีเหล่านี้มีผลบังคับใช้กับฐานข้อมูลหรือไม่
คำตอบ:
เป็นไปไม่ได้ที่จะบอกว่าการออกแบบฐานข้อมูลเฉพาะนั้นไม่ดีโดยไม่ทราบว่าแอปพลิเคชันกำลังทำอะไรอยู่รูปร่างของข้อมูลการคาดการณ์ประสิทธิภาพเป็นต้น ในขณะที่โดยทั่วไปการทำให้เป็นมาตรฐาน (ในระดับหนึ่ง) ถูกมองว่าเป็นแนวปฏิบัติที่ดีที่สุด แต่ก็เป็นเรื่องธรรมดาที่พื้นที่ฐานข้อมูลผิดปกติด้วยเหตุผลด้านประสิทธิภาพการทำงานที่ดีและไม่ดีจะเปิดกว้างสำหรับการสนทนาโดยไม่มีข้อมูลมาก
เพิ่มวิธีการมากมายที่สามารถนำไปใช้กับวัตถุในการแมปเชิงสัมพันธ์และสิ่งต่าง ๆ มีความซับซ้อนมากขึ้นเนื่องจากโครงสร้างฐานข้อมูล "ดีที่สุด" จะขึ้นอยู่กับโมเดลวัตถุเฉพาะระดับการสืบทอดและอื่น ๆ
ด้วยการใช้ขนาดเดียวเหมาะกับวิธีการคงอยู่ของไลบรารี ORM เกือบทุกครั้งจะสร้างโครงสร้างฐานข้อมูลที่ไม่เหมาะสมที่สุดสำหรับสถานการณ์ใด ๆ และจะใช้บางสิ่งที่สามารถเห็นได้ว่าเป็นการปฏิบัติที่ไม่ดีสำหรับสถานการณ์นั้น ๆ
แน่นอนว่าคุณสามารถเขียน ORM ที่ทำให้เป็นมาตรฐานได้ แต่คุณจะเห็นความหมายของประสิทธิภาพการทำงานที่ค่อนข้างหนักสำหรับการแทรกทุกครั้งลงในตารางหลักจำเป็นต้องสแกนตารางค้นหาต่างๆเพื่อดูว่ามีค่าอยู่หรือไม่หากพวกเขาได้รับกุญแจ ไม่ต้องดำเนินการแทรกที่เกี่ยวข้อง
(เมื่อคุณทำสิ่งนี้ด้วยมือคุณสามารถตัดบางส่วนได้ตามที่คุณรู้ว่าคุณแสดงมันด้วยรายการแบบหล่นลงที่มีค่าที่ถูกต้องเท่านั้นดังนั้นคุณไม่จำเป็นต้องค้นหาสิ่งเหล่านี้คุณเพียงแค่ใช้กุญแจที่มีความสุข จะถูกต้อง ORM ไม่สามารถสร้างสมมติฐานได้เนื่องจากไม่ได้ควบคุม UI)
แต่สิ่งที่คุณต้องจำไว้ก็คือพวกเขาไม่ได้ตั้งเป้าหมายที่จะปรับประสิทธิภาพของฐานข้อมูลหรือความถูกต้องของข้อมูลให้ดีที่สุด หากโครงสร้างเฉพาะของข้อมูลของคุณมีความสำคัญต่อคุณคุณจำเป็นต้องใช้รหัสการแมป object / RDBMS ด้วยมือหรืออย่างน้อยที่สุดทำการประเมินรายละเอียดของไลบรารีทั้งหมดที่มีอยู่และเลือกโครงสร้างที่ตรงกับความต้องการของคุณมากที่สุด ( ถ้ามี)
โดยพื้นฐานแล้วจะเป็นไปตามข้อกำหนดและการแลกเปลี่ยนระหว่างข้อมูลที่มีโครงสร้างดีประสิทธิภาพของฐานข้อมูลและความเร็วในการพัฒนา เช่นเดียวกับการแลกเปลี่ยนหลายครั้งคุณไม่ได้เลือกทั้งสามอย่าง
ตามกฎทั่วไปอย่าทำแบบจำลองข้อมูลของคุณเพื่อตอบสนองความต้องการของนักพัฒนา (คุณสามารถใช้ Views หรือ Sp สำหรับสิ่งนั้น แต่ไม่ใช่ตัวแบบข้อมูล)
ตัวแบบข้อมูลควรเป็นไปตามกฎเกณฑ์ทางธุรกิจของแอปพลิเคชันและความต้องการด้านประสิทธิภาพ
ฉันไม่เห็นด้วยว่า ORM ส่งเสริมการลดความผิดปกติหรือการออกแบบฐานข้อมูลไม่ดี อันที่จริงแล้วฐานข้อมูลที่ออกแบบมาแย่ที่สุดที่ฉันเคยเห็นมานั้นผ่าน ORM แล้ว โดยทำให้มันง่ายที่จะมีความสัมพันธ์ที่เหมาะสมบนพื้นฐานของ id แถวแทนที่จะทำให้ความสัมพันธ์ตามมูลค่าของเขตข้อมูลแบบสุ่มมันค่อนข้างส่งเสริมการออกแบบฐานข้อมูลที่ดี
อาจเป็นไปได้ว่ามันไม่ได้ส่งเสริมการทำให้เป็นมาตรฐาน แต่อีกครั้งเป็น ORM ที่ทำให้การสร้างตาราง / วัตถุและความสัมพันธ์นั้นเป็นเรื่องง่าย มันไม่ได้ทำงานมากขึ้นใน ORM เพื่อสร้างตาราง "สถานที่" ที่มีที่อยู่และเชื่อมโยงพนักงานกับสถานที่แทนการเพิ่มที่อยู่ลงในตารางพนักงาน แต่ถ้าไม่มี ORM การแยกที่ตั้งก็หมายความว่าทุกครั้งที่คุณต้องการเข้าถึงที่ตั้งเช่นกันคุณต้องทำการเข้าร่วม
ดังนั้นคำตอบของฉันคือ: ไม่ฉันไม่คิดอย่างนั้น มันอาจเป็นไปได้ในทางอื่น ORM ที่ดีจะส่งเสริมการออกแบบฐานข้อมูลที่ดีอย่างน้อยก็เกี่ยวกับผู้ที่มีประสบการณ์น้อย