ใช้ ORM หรือ SQL ธรรมดา? [ปิด]

สำหรับแอพบางตัวที่ฉันพัฒนาขึ้นมา (จากนั้นก็ลืมไปเรื่อย ๆ ) ฉันเขียน SQL ธรรมดา ๆ สำหรับ MySQL เป็นหลัก แม้ว่าฉันจะใช้ ORMs ในไพ ธ อนเช่นSQLAlchemyแต่ฉันไม่ได้ติดกับมันนานนัก โดยปกติแล้วเป็นทั้งเอกสารหรือความซับซ้อน (จากมุมมองของฉัน) ถือฉันกลับมา

ฉันเห็นว่ามันเป็นเช่นนี้: ใช้ ORM เพื่อความสะดวกในการพกพา, SQL ธรรมดา ๆ ถ้ามันจะใช้ฐานข้อมูลประเภทเดียว ฉันกำลังมองหาคำแนะนำเกี่ยวกับเวลาที่จะใช้ ORM หรือ SQL เมื่อพัฒนาแอพที่ต้องการการสนับสนุนฐานข้อมูล

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

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

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

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

ฉันพบแอปพลิเคชันขนาดใหญ่ที่คุณจะพบว่าตัวเองใช้ทั้งสองวิธี (ORM สำหรับ CRUD ที่ตรงไปตรงมาและ SQL / thin DAL สำหรับการรายงาน)

การพูดว่าเป็นคนที่ใช้เวลาทำงานกับ JPA (Java Persistence API โดยทั่วไปจะเป็นมาตรฐาน ORM API สำหรับ Java / J2EE / EJB) ซึ่งรวมถึง Hibernate, EclipseLink, Toplink, OpenJPA และอื่น ๆ ฉันจะแบ่งปันบางส่วนของฉัน ข้อสังเกต

1. ORMs ไม่เร็ว พวกเขาสามารถเพียงพอและส่วนใหญ่เวลาที่เพียงพอก็โอเค แต่ในสภาพแวดล้อมที่มีความล่าช้าต่ำปริมาณสูงพวกเขาจะไม่มี
2. โดยทั่วไปแล้วการเขียนโปรแกรมภาษาเช่น Java และ C # คุณต้องใช้เวทย์มนตร์มากมายที่จะทำให้มันทำงานได้ (เช่นการทอโหลดใน Java, การใช้เครื่องมือ, ฯลฯ );
3. เมื่อใช้ ORM แทนที่จะได้รับเพิ่มเติมจาก SQL (ซึ่งดูเหมือนจะเป็นเจตนา) คุณจะประหลาดใจว่าคุณใช้เวลาปรับแต่ง XML และ / หรือคำอธิบายประกอบ / แอตทริบิวต์เพื่อให้ ORM ของคุณสร้าง SQL ที่มีประสิทธิภาพ
4. สำหรับข้อความค้นหาที่ซับซ้อนจะไม่มีสิ่งทดแทน เช่นเดียวกับใน JPA มีแบบสอบถามบางอย่างที่เป็นไปไม่ได้ที่อยู่ใน SQL ดิบและเมื่อคุณต้องใช้ SQL ดิบใน JPA มันไม่สวย (C # /. สุทธิอย่างน้อยมีประเภทไดนามิก - var - ซึ่งเป็นจำนวนมาก ดีกว่าอาเรย์ Object);
5. มี "gotchas" อันน่ากลัวมากมายเมื่อใช้ ORM ซึ่งรวมถึงพฤติกรรมที่ไม่ได้ตั้งใจหรือไม่คาดคิดความจริงที่ว่าคุณต้องสร้างความสามารถในการอัปเดต SQL ไปยังฐานข้อมูลของคุณ (โดยใช้การรีเฟรช () ใน JPA หรือวิธีที่คล้ายกันเพราะ JPA โดยค่าเริ่มต้นแคชทุกอย่าง update - การรันการอัพเดต SQL โดยตรงเป็นกิจกรรมสนับสนุนการผลิตทั่วไป);
6. ความไม่ตรงกันของวัตถุสัมพันธ์จะทำให้เกิดปัญหาเสมอ กับปัญหาดังกล่าวมีการแลกเปลี่ยนระหว่างความซับซ้อนและความสมบูรณ์ของสิ่งที่เป็นนามธรรม ในบางครั้งฉันรู้สึกว่า JPA ไปไกลเกินไปและตีกฎที่แท้จริงของผลตอบแทนที่ลดน้อยลงซึ่งความซับซ้อนของการตีไม่ได้เป็นสิ่งที่ชอบธรรมจากสิ่งที่เป็นนามธรรม

มีปัญหาอีกข้อหนึ่งซึ่งใช้เวลาอธิบายเพิ่มเติมเล็กน้อย

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

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

สิ่งที่เป็นปัญหาเหล่านั้นไม่ได้หายไปกับ ORM เพียง แต่เลื่อนไปยังเลเยอร์การนำเสนอ แทนที่จะสร้าง VOs / DTO สำหรับคิวรีคุณสร้างออบเจกต์การนำเสนอที่กำหนดเองซึ่งมักจะเป็นหนึ่งสำหรับทุกมุมมอง มันจะดีกว่านี้อย่างไร IMHO มันไม่ใช่

ฉันได้เขียนเกี่ยวกับเรื่องนี้ในORM หรือ SQL: เรายังอยู่หรือเปล่า? .

เทคโนโลยีการคงอยู่ของฉันที่เลือก (ใน Java) วันนี้คือ ibatis มันเป็น wrapper สวย ๆ เกี่ยวกับ SQL ซึ่งทำ 90% + ของสิ่งที่ JPA สามารถทำได้ (สามารถทำได้แม้กระทั่งการโหลดความสัมพันธ์แบบขี้เกียจแม้ว่ามันจะไม่ได้รับการบันทึกไว้อย่างดีก็ตาม) แต่มีค่าใช้จ่ายน้อยกว่ามาก

ปีนี้เกิดขึ้นในแอปพลิเคชัน GWT ที่ฉันเขียน การแปลจำนวนมากจาก EclipseLink ไปยังวัตถุการนำเสนอในการใช้งานบริการ ถ้าเราใช้ ibatis มันคงจะง่ายกว่าที่จะสร้างวัตถุที่เหมาะสมด้วย ibatis แล้วส่งพวกมันไปเรื่อย ๆ จนถึงกองซ้อน นักพิถีพิถันบางคนอาจโต้แย้งว่านี่คือ Bad ™ อาจเป็นไปได้ (ในทางทฤษฎี) แต่ฉันบอกคุณว่า: มันจะนำไปสู่โค้ดที่ง่ายกว่า, สแต็กที่ง่ายกว่า

ผมพูด SQL ธรรมดาสำหรับR EADS, ออมสำหรับCUD

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

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

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

แก้ไขเพื่อตอบสนองต่อความคิดเห็นที่ขอให้ฉันอธิบายถึงวิธีแยก DAL จาก ORM:

DAL คือสิ่งที่คุณเขียนเองอาจจะเริ่มจากชั้นเรียนที่เพียงแค็ปซูลตารางและแมปฟิลด์ไปยังคุณสมบัติ ORM เป็นรหัสที่คุณไม่ได้เขียนหรือกลไกการอนุมานที่อนุมานจากคุณสมบัติอื่น ๆ ของ schema dbms ของคุณซึ่งส่วนใหญ่เป็น PKs และ FKs (นี่คือที่ที่คุณทราบว่า abstractions อัตโนมัติเริ่มรั่วหรือไม่ฉันชอบที่จะแจ้งให้ทราบโดยเจตนา แต่นั่นอาจเป็นความชอบส่วนตัวของฉัน)

เครื่องมือทุกชิ้นมีวัตถุประสงค์และวิสัยทัศน์ ฉันได้สร้างhttp://www.jooq.org/ให้ตรงกับความต้องการของคุณแม้ว่า iBatis อาจเป็นทางออกที่ดีสำหรับคุณเช่นกัน

jOOQ มีคุณสมบัติ ORM ขั้นพื้นฐาน แต่ส่วนใหญ่เน้นไปที่สิ่งที่ฉันคิดว่านักพัฒนาส่วนใหญ่ต้องการมากที่สุดเมื่อพยายามหา ORM ที่ดีที่สุดสำหรับความต้องการของพวกเขา:

• การสร้างรหัส
• การรวมตัวแปร (ซึ่งเป็นความเจ็บปวดใน JDBC)
• SQL abstraction นามธรรม (เพื่อป้องกันข้อผิดพลาดทางไวยากรณ์)

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

• มันเป็นแหล่งข้อมูลที่แข็งแกร่ง
• SQL สามารถทำสิ่งที่ดีหลายอย่างได้ดี (เลือกซ้อน, สหภาพ, การรวมที่ซับซ้อน ฯลฯ ) บ่อยครั้งที่ ORM ไม่สามารถทำสิ่งเหล่านี้ได้
• คุณสามารถจัดการธุรกรรมและเซสชันด้วยตัวคุณเอง
• คุณมี UDT และขั้นตอนการจัดเก็บ

jOOQ พูดถึงประเด็นเหล่านี้อย่างแน่นอน มันจะทำงานได้ดีเช่นเดียวกับ JDBC แต่ไม่มีอาการปวด

ขึ้นเขียงว่าจะใช้กรอบงานหรือไม่เป็นเรื่องธรรมดาในสถานการณ์การพัฒนาซอฟต์แวร์ยุคใหม่

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

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

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

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

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

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

ไม่มีวิธีแก้ปัญหา 'เครื่องมือเดียวที่เหมาะกับทุกคน' และนี่ก็เป็นจริงสำหรับคำถาม 'ฉันควรใช้หรือ / m หรือไม่? '

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

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

หนึ่งในแอพที่ฉันพัฒนาขึ้นคือ IRC bot ที่เขียนด้วยไพ ธ อน โมดูลที่ใช้รันในเธรดแยกกัน แต่ฉันไม่ได้หาวิธีจัดการเธรดเมื่อใช้ sqlite แม้ว่ามันอาจจะดีกว่าสำหรับคำถามแยกต่างหาก

ผมควรจะได้ reworded เพียงทั้งชื่อและคำถามที่เกิดขึ้นจริง ฉันไม่เคยใช้ DAL มาก่อนในทุกภาษา

ใช้ ORM ที่ทำงานเช่น SQL แต่ให้ตรวจสอบเวลาคอมไพล์และความปลอดภัยของประเภท เช่นเดียวกับที่ชื่นชอบ: Data Knowledge Objects (การเปิดเผย: ฉันเขียน)

ตัวอย่างเช่น:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

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

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

ดูข้อมูล SQL ( http://sqldata.codeplex.com ) มันเป็น ORM น้ำหนักเบามากสำหรับ c # ที่ครอบคลุมฐานทั้งหมด

FYI ฉันเป็นผู้เขียนข้อมูล SQL

ฉันต้องการเพิ่มเสียงของฉันไปยังคอรัสของคำตอบที่พูดว่า "มีพื้นกลาง!"

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

สิ่งที่ฉันต้องการเสมอคือเลเยอร์ (เรียกว่า DAL, ORM หรือ micro-ORM ฉันไม่รังเกียจที่) ที่จะรับผิดชอบการตัดสินใจที่คาดเดาได้อย่างสมบูรณ์ (วิธีสะกดคำสำคัญของ SQL เมื่อวงเล็บอยู่ตรงไหน เพื่อสร้างคอลัมน์แทนนามแฝงคอลัมน์ใดที่จะสร้างสำหรับคลาสที่มีสองโฟลว์และ int ... ) ในขณะที่ปล่อยให้ฉันรับผิดชอบด้านที่สูงกว่าของ SQL เช่นการจัด JOINs การคำนวณฝั่งเซิร์ฟเวอร์ DISTINCTs, GROUP BYs, เคียวรี่ย่อย scalar, เป็นต้น

ดังนั้นฉันจึงเขียนสิ่งที่ทำสิ่งนี้: http://quince-lib.com/

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