ประโยชน์ของการใช้ฐานข้อมูลนามธรรมโดย ORM คืออะไร [ปิด]

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

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

ถ้าฉันรู้ว่าในระยะยาวฉันจะไม่เปลี่ยนฐานข้อมูลพื้นฐาน ทำไมไม่เข้าถึงคุณลักษณะเฉพาะฐานข้อมูลด้วย

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

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

IMO ORM ใด ๆ ที่ไม่มีคุณสมบัตินี้ไม่คุ้มค่าบิตที่รวบรวมจาก

ORM ใช้ตัวหารร่วมที่ต่ำที่สุด

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

บันทึกย่อ: คุณพูดถึงสิ่งที่เป็นนามธรรมเท่านั้น นั่นเป็นหนึ่งในผลประโยชน์มากมาย แต่ฉันคิดว่าคุณสมบัติเชิงวัตถุมีประสิทธิภาพมากขึ้น (เช่น: การสืบทอด) และYou design your domain model first...

... กลับไปที่สิ่งที่เป็นนามธรรม มันไม่ใช่ตัวส่วนร่วมที่ต่ำที่สุด ในnHibernateคุณมีภาษาถิ่น จะช่วยให้คุณใช้รหัสเดียวกันเพื่อสอบถามฐานข้อมูลที่แตกต่างกัน ภาษาถิ่นดูแลการจัดการคุณสมบัติสำหรับคุณ a given dialect will try to use all the power of a given database systemคำสั่งที่ถูกต้องคือ

ในฐานะที่เป็นตัวอย่างใช้SqlServer2005ภาษาที่เมื่อนำมาใช้คือการใช้ประโยชน์จากคุณลักษณะการเพจจิ้ง SQL Server 2005 ใหม่ การใช้ภาษาถิ่นนั้นแทนที่จะSqlServer2000เพิ่มการแสดงของคุณ

แน่นอนว่ามีข้อยกเว้น แต่ฉันไม่ได้พบกับคนเดียวในหลายปีที่ทำงานกับ nHibernate และแอปพลิเคชันของฉันเป็นศูนย์กลางข้อมูลมาก

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

ดังนั้นฉันเดาคำถามที่ควรจะเป็นก่อนที่คุณจะกระโดดเข้าที่:

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

จากนั้นเลเยอร์นามธรรมพิเศษจะมีผลกระทบกับแอพหรือไม่ มันจะช้ากว่า SQL ที่เขียนด้วยมือหรือไม่

O / RM ถูกวิจารณ์อย่างสม่ำเสมอ Ted Neward เรียกมันว่า " Vietnam of Computer Science " เมื่อไม่กี่ปีที่ผ่านมา O / RM

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

หากคุณไม่ได้เขียนการแมปเฉพาะกิจ (ซึ่งเป็นวิธีแก้ปัญหาที่ดีในหลาย ๆ กรณีตามที่ได้กล่าวไปแล้ว) คุณสามารถดูทางเลือกอื่น ๆ เช่นการใช้ฐานข้อมูลที่ไม่เกี่ยวข้อง บางคนบอกว่าฐานข้อมูลวัตถุจริงดีกว่า buzzwords อื่น ๆ ที่กล่าวถึงในบริบทนี้คือ LINQ, Ruby และ Tutorial D. ฉันคิดว่าตรงกันข้ามกับฐานข้อมูลเชิงสัมพันธ์อย่างแท้จริงมีฐานข้อมูลวัตถุจริง แต่ในทางปฏิบัติแล้วฉันพบว่าการสร้างแบบจำลองข้อมูลแนวคิด - นั่นคือการค้นหาวัตถุในโลกแห่งความจริงที่คุณต้องการจัดเก็บข้อมูลเกี่ยวกับและวัตถุเหล่านี้เกี่ยวข้องกับกันและกันอย่างไร - มีความสำคัญยิ่งกว่า ภาษาโปรแกรมหรือฐานข้อมูล

ทางเลือกคืออะไร

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

ในตอนท้ายของวันคุณต้องถามตัวเองว่า - อะไรคือทางเลือก?

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

ORM นั้นโดยทั่วไปจะเป็น " Unstored กระบวนงาน " ฉันประกาศคำหนึ่งคำ

ทุกสิ่งที่ ORM ทำคุณสามารถทำซ้ำกับวิวทริกเกอร์และกระบวนงานที่เก็บไว้ พวกเขาช่วยแยก SQL ดิบออกไปและสามารถทำให้ฐานข้อมูลปกติสอดคล้องกัน แต่ใช้งานได้ดีกับกรณีง่าย ๆ เท่านั้น หากมีข้อมูลจักรเกินกว่าที่จะประมวลผลข้อมูลเหล่านั้นอาจกลายเป็นประสิทธิภาพที่ลดลง (ORMs ใน PHP มักจะใช้ data-side script, เนื่องจากตัวสร้าง SQL chains ไม่สามารถสรุปได้ทุกอย่าง)

แต่ตามปกติทุกอย่างขึ้นอยู่กับแอปพลิเคชันและงานที่ทำอยู่

สิ่งหนึ่งที่ทำร้ายการใช้ ORMs คือแฟน ๆ ของพวกเขาจำนวนมากมักอ้างว่าเราไม่จำเป็นต้องรู้ทฤษฎี SQL และ RDB อีกต่อไป ผลลัพธ์ที่ได้นั้นแตกต่างกันไปจากเรื่องตลกไปจนถึงเรื่องหายนะอย่างสิ้นเชิง และนี่คือแม้จะเป็นล้านเท่าที่ ORM ผลิตและผู้เชี่ยวชาญกล่าวว่าเราต้องรู้จักทฤษฎี SQL และ RDB เป็นอย่างดีเพื่อใช้และกำหนดค่า ORM อย่างถูกต้อง

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

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

ขอบคุณ ORM ( Propelใน PHP) เราแบ่งตรรกะบางส่วนสำหรับโค้ดดังนั้นหนึ่งฟังก์ชันเพิ่มส่วน "is record valid valid" ของแบบสอบถามอีกส่วนความปลอดภัย ("แสดงบันทึกเหล่านี้เฉพาะในกรณีที่ผู้ใช้ มีความสามารถเหล่านี้ "), ... หากมีการเปลี่ยนแปลงโครงสร้างพื้นฐาน (เขตข้อมูลเพิ่มเติมที่ควรนำมาพิจารณาสำหรับ" ความถูกต้องของเร็กคอร์ด ") เราจะต้องเปลี่ยนหนึ่งฟังก์ชันไม่ใช่ยี่สิบประโยคของ SQL

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

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

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

ฉันทำงานใน C # ตอนนี้และใช้ LINQ เป็นจำนวนมากดังนั้นวิธีการที่คล่องแคล่วมากมาย ฉันไม่จำเป็นต้องคิดเกี่ยวกับวิธีการจัดเก็บหรือค้นหาวัตถุของฉันหรือบันทึกในระดับโปรแกรมและน้อยมากที่ระดับเลเยอร์ธุรกิจ

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

คุณยังสามารถเขียนฟังก์ชัน DB-side บ่อยครั้งที่คุณสามารถทำแผนที่ผ่าน

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

ORMs สามารถให้คุณสามารถเข้าถึงฐานข้อมูลที่เฉพาะเจาะจงให้บริการได้เป็นอย่างดีก็ขึ้นอยู่กับที่ออมที่คุณใช้และสิ่งที่มีก็มี

ตัวอย่างเช่นในโครงการปัจจุบันที่ฉันกำลังดำเนินการเรากำลังใช้ Java Persistence API และ Hibernate ถึงกระนั้นก็ตามเราใช้คุณสมบัติเฉพาะของฐานข้อมูลหลายอย่างเช่นการค้นหาในตารางที่มี soundex

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

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

ฉันเขียนของตัวเองซึ่งช่วยให้ฉันเลือกและแทรกได้ง่ายขึ้น

สิ่งเฉพาะ Evey db พร้อมใช้งาน ฉันต้องเขียนแบบสอบถามด้วยตนเองซึ่งห้องสมุดช่วยเหลือฉันด้วย (ฉันสามารถใช้ '?' และ params แทนการตั้งชื่อพารามิเตอร์ด้วยตนเองและใช้. เพิ่ม)

ฉันเดาว่าครึ่งนึงของฉันมีประโยชน์จริงๆ ฉันได้รับความช่วยเหลือในโลกแห่งออมและทำส่วนสำคัญในโลกแห่งการสืบค้น

การเขียนรหัสเพื่อแทรกและเลือกอัปเดตแบบอินไลน์หรือด้วย procs ที่จัดเก็บไว้และการจับคู่กลับเข้าไปใน DAL นั้นมีความยาวมากกว่าปกติ แต่มีประโยชน์เฉพาะในกรณีพิเศษเท่านั้น ORM ที่มีอยู่ฐานข้อมูลสนับสนุนและภาษาที่คุณควรถามว่าทำไมคุณไม่ใช้ ORM

พวกเขากำลังมาตรฐานสากลทั้งที่ระบุหรือทั่วไป ยิ่งไปกว่านั้นมันยังเร็วและง่ายต่อการนำไปใช้ ฉันใช้ subsonic, linq-to-sql และ framework อนุญาตให้ผู้พัฒนามุ่งเน้นไปที่ตรรกะและกฎทางธุรกิจแทนการแมปฐานข้อมูล

สองเซ็นต์ของฉัน (ง่าย):

1: มี ORMS และมี ORMS ORMS บางตัวอยู่บนพื้นฐานของ Active Record และอื่น ๆ ที่อยู่บน Data Mapper นั่นก็คือการพิจารณาที่เกี่ยวข้อง แต่สิ่งหนึ่งที่ต้องมีการสอบสวนเพื่อทำความเข้าใจความหมาย โดยทั่วไป - ประสบการณ์ของฉันใน PHP คือ ORMS สนับสนุนอดีตไม่กี่สนับสนุนหลัง Active Record based ORMs ดูเหมือนจะมีหนึ่งในสองเอฟเฟกต์ - พวกมันอาจทำให้ฐานข้อมูลปกติหรือเรียกคลาสที่เหลือเฟือเพื่อสนับสนุนการโต้ตอบกับวัตถุ

2: ข้อดีของ ORMs ลดลงโดยสัมพันธ์โดยตรงกับความซับซ้อนของคิวรีที่คุณต้องการเรียกใช้ เมื่อคุณมีความสัมพันธ์ที่ดีง่ายๆ - เช่นผู้ใช้ -> โพสต์พวกเขาสามารถทำงานได้ดีมาก นี่คือเหตุผลที่ ORMs / framework ส่วนใหญ่ใช้ตัวอย่างเช่นนี้ เมื่อคุณต้องการเรียกใช้คิวรีที่ซับซ้อนอย่างไรก็ตามจำนวนของ ORMQL ที่คุณต้องการสร้างนั้นเทียบได้กับความยาวสตริงของเคียวรี SQL ปกติ - แต่มีประสิทธิภาพน้อยกว่าเนื่องจากกราฟวัตถุที่ใช้เคียวรีเรียกซึ่งชนิดของจุดที่เอาชนะ สิ่งที่เป็นนามธรรม สรุปสั้น ๆ ว่า ORM นั้นยอดเยี่ยมสำหรับงานฐานข้อมูลของคุณ 30-50% แรก แต่แย่มากในช่วงสุดท้าย ฉันคิดว่านี่เป็นอีกเหตุผลว่าทำไม AR จึงแพร่หลาย

3: ทำไมซ่อนจากฐานข้อมูล คุณจะใช้ภาษาฝั่งเซิร์ฟเวอร์เพื่อจาวาสคริปต์ที่เป็นนามธรรมหรือไม่?

ส่วนตัวฉันผสมผสานวิธีการเหล่านั้น:

• ใช้ ORM สำหรับพื้นฐานโหลด "ผู้ใช้"
• ใช้ DAO ที่มีแบบสอบถาม SQL ล่วงหน้าหลายรายการ (เช่น selectLike, selectWhere)
• ขยาย DAO เมื่อจำเป็นเพื่อเพิ่มแบบสอบถามที่กำหนดเองที่เฉพาะเจาะจง แต่สามารถใช้งานได้อีกครั้ง
• จัดเตรียมการเข้าถึงฐานข้อมูลอย่างง่ายผ่าน DAO - เช่น $ data = Dao-> แบบสอบถาม (สตริง sql ของคุณ) เพื่อดำเนินการค้นหาหนึ่งครั้ง

เมื่อกล่าวทั้งหมดนี้ Doctrine 2 จะออกมาเร็ว ๆ นี้ซึ่งดูน่าสนใจจริงๆ

คุณสามารถใช้เฟรมเวิร์กตัวแมป SQL เช่น myBatis ถ้าคุณต้องการใช้คุณสมบัติของ sql