Sử dụng ORM hoặc SQL đơn giản? [đóng cửa]

Đối với một số ứng dụng tôi đã phát triển (sau đó tiến hành quên), tôi đã viết SQL đơn giản, chủ yếu cho MySQL. Mặc dù tôi đã sử dụng ORM trong python như SQLAlchemy , tôi đã không gắn bó lâu dài với chúng. Thông thường, đó là tài liệu hoặc sự phức tạp (theo quan điểm của tôi) giữ tôi lại.

Tôi thấy nó như thế này: sử dụng ORM cho tính di động, SQL đơn giản nếu nó chỉ sử dụng một loại cơ sở dữ liệu. Tôi thực sự đang tìm kiếm lời khuyên khi nào nên sử dụng ORM hoặc SQL khi phát triển ứng dụng cần hỗ trợ cơ sở dữ liệu.

Nghĩ về nó, sẽ tốt hơn nhiều nếu chỉ sử dụng một trình bao bọc nhẹ để xử lý sự không nhất quán của cơ sở dữ liệu so với sử dụng ORM.

ORM có một số tính năng tốt đẹp. Họ có thể xử lý phần lớn công việc chó sao chép các cột cơ sở dữ liệu vào các trường đối tượng. Họ thường xử lý việc chuyển đổi các loại ngày và giờ của ngôn ngữ sang loại cơ sở dữ liệu thích hợp. Họ thường xử lý các mối quan hệ một-nhiều khá thanh lịch bằng cách khởi tạo các đối tượng lồng nhau. Tôi đã tìm thấy nếu bạn thiết kế cơ sở dữ liệu của mình với các điểm mạnh và điểm yếu của ORM, nó sẽ tiết kiệm rất nhiều công việc trong việc lấy dữ liệu vào và ra khỏi cơ sở dữ liệu. (Bạn sẽ muốn biết làm thế nào nó xử lý đa hình và mối quan hệ nhiều-nhiều nếu bạn cần lập bản đồ. Hai miền này cung cấp hầu hết 'sự không phù hợp trở kháng' khiến một số người gọi ORM là 'Việt Nam của khoa học máy tính' .)

Đối với các ứng dụng giao dịch, tức là bạn đưa ra yêu cầu, nhận một số đối tượng, duyệt qua chúng để lấy một số dữ liệu và hiển thị nó trên trang Web, thuế hiệu suất rất nhỏ và trong nhiều trường hợp, ORM có thể nhanh hơn vì nó sẽ lưu trữ các đối tượng đã thấy trước đó, nếu không thì sẽ truy vấn cơ sở dữ liệu nhiều lần.

Đối với các ứng dụng nặng về báo cáo hoặc xử lý một số lượng lớn các hàng cơ sở dữ liệu cho mỗi yêu cầu, thuế ORM nặng hơn nhiều và bộ nhớ đệm mà chúng biến thành một gánh nặng lớn trong bộ nhớ vô dụng. Trong trường hợp đó, ánh xạ SQL đơn giản (LinQ hoặc iBatis) hoặc các truy vấn SQL được mã hóa bằng tay trong một DAL mỏng là cách để đi.

Tôi đã tìm thấy cho bất kỳ ứng dụng quy mô lớn nào, bạn sẽ thấy mình sử dụng cả hai phương pháp. (ORM cho CRUD đơn giản và SQL / DAL mỏng để báo cáo).

Nói như một người đã dành khá nhiều thời gian làm việc với JPA (API liên tục Java, về cơ bản là API ORM được tiêu chuẩn hóa cho Java / J2EE / EJB), bao gồm Hibernate, EclipseLink, Toplink, OpenJPA và những người khác, tôi sẽ chia sẻ một số quan sát.

1. ORM không nhanh. Chúng có thể đầy đủ và hầu hết thời gian phù hợp là OK nhưng trong môi trường độ trễ thấp khối lượng lớn, chúng là không có;
2. Trong các ngôn ngữ lập trình mục đích chung như Java và C #, bạn cần rất nhiều phép thuật để làm cho chúng hoạt động (ví dụ: dệt thời gian tải trong Java, thiết bị, v.v.);
3. Khi sử dụng ORM, thay vì nhận thêm từ SQL (dường như là mục đích), bạn sẽ ngạc nhiên về việc bạn dành bao nhiêu thời gian để điều chỉnh XML và / hoặc chú thích / thuộc tính để ORM của bạn tạo SQL hiệu quả;
4. Đối với các truy vấn phức tạp, thực sự không có thay thế. Giống như trong JPA, có một số truy vấn đơn giản là không thể có trong SQL thô và khi bạn phải sử dụng SQL thô trong JPA, nó không đẹp (C # /. Net ít nhất có các kiểu động - var - rất nhiều đẹp hơn một mảng Object);
5. Có rất nhiều "gotchas" khi sử dụng ORM. Điều này bao gồm hành vi ngoài ý muốn hoặc không mong muốn, thực tế là bạn phải xây dựng khả năng thực hiện cập nhật SQL cho cơ sở dữ liệu của mình (bằng cách sử dụng refresh () trong JPA hoặc các phương thức tương tự vì mặc định JPA lưu trữ mọi thứ để nó không bắt được cơ sở dữ liệu trực tiếp cập nhật - chạy cập nhật SQL trực tiếp là một hoạt động hỗ trợ sản xuất phổ biến);
6. Sự không phù hợp quan hệ đối tượng luôn luôn gây ra vấn đề. Với bất kỳ vấn đề nào như vậy, có một sự đánh đổi giữa sự phức tạp và tính đầy đủ của sự trừu tượng. Đôi khi tôi cảm thấy JPA đã đi quá xa và đạt được một quy luật thực sự về lợi nhuận giảm dần trong đó mức độ phức tạp không được chứng minh bằng sự trừu tượng.

Có một vấn đề khác cần thêm một chút giải thích.

Mô hình truyền thống cho một ứng dụng Web là có một lớp kiên trì và một lớp trình bày (có thể có một dịch vụ hoặc các lớp khác ở giữa nhưng đây là hai lớp quan trọng cho cuộc thảo luận này). Các ORM buộc một cái nhìn cứng nhắc từ lớp kiên trì của bạn lên đến lớp trình bày (tức là các thực thể của bạn).

Một trong những lời chỉ trích về các phương thức SQL thô hơn là bạn kết thúc với tất cả các VO (đối tượng giá trị) hoặc DTO (đối tượng truyền dữ liệu) được sử dụng chỉ bằng một truy vấn. Điều này được quảng cáo là một lợi thế của ORM vì bạn thoát khỏi điều đó.

Điều đó là những vấn đề không biến mất với ORM, chúng chỉ đơn giản là chuyển lên lớp trình bày. Thay vì tạo VO / DTO cho các truy vấn, bạn tạo các đối tượng trình bày tùy chỉnh, thường là một đối tượng cho mỗi chế độ xem. Làm thế nào là tốt hơn? IMHO không phải vậy.

Tôi đã viết về điều này trong ORM hoặc SQL: Chúng ta đã ở đó chưa? .

Công nghệ kiên trì lựa chọn của tôi (trong Java) những ngày này là ibatis. Đó là một trình bao bọc khá mỏng xung quanh SQL, thực hiện 90% + những gì JPA có thể làm (thậm chí nó có thể thực hiện các mối quan hệ lười biếng mặc dù nó không được ghi chép đầy đủ) nhưng với chi phí thấp hơn nhiều (về độ phức tạp và mã thực tế).

Điều này đã xuất hiện vào năm ngoái trong một ứng dụng GWT mà tôi đang viết. Rất nhiều bản dịch từ EclipseLink sang các đối tượng trình bày trong triển khai dịch vụ. Nếu chúng ta đang sử dụng ibatis, việc tạo các đối tượng phù hợp với ibatis sẽ đơn giản hơn rất nhiều và sau đó chuyển chúng lên và xuống ngăn xếp. Một số người theo chủ nghĩa thuần túy có thể cho rằng đây là Bad ™. Có thể là như vậy (về lý thuyết) nhưng tôi nói với bạn điều gì: nó sẽ dẫn đến mã đơn giản hơn, ngăn xếp đơn giản hơn và năng suất cao hơn.

Tôi nói SQL đơn giản cho các đầu R , ORM cho CUD .

Hiệu suất là điều tôi luôn quan tâm, đặc biệt trong các ứng dụng web, nhưng cũng có thể duy trì mã và khả năng đọc. Để giải quyết những vấn đề này tôi đã viết SqlBuilder .

ORM không chỉ là tính di động (điều này hơi khó đạt được ngay cả với ORM, đối với vấn đề đó). Những gì nó mang lại cho bạn về cơ bản là một lớp trừu tượng trên một cửa hàng liên tục, khi một công cụ ORM giải phóng bạn khỏi việc viết các truy vấn SQL soạn sẵn (chọn bởi PK hoặc bằng các vị từ, chèn, cập nhật và xóa) và cho phép bạn tập trung vào miền vấn đề.

Bất kỳ thiết kế đáng kính nào cũng sẽ cần một số trừu tượng cho cơ sở dữ liệu, chỉ để xử lý sự không phù hợp trở kháng. Nhưng bước đầu tiên đơn giản nhất (và đầy đủ cho hầu hết các trường hợp) tôi mong đợi sẽ là DAL, không phải là ORM hạng nặng. Tùy chọn duy nhất của bạn không phải là những lựa chọn ở cuối phổ.

EDIT để phản hồi bình luận yêu cầu tôi mô tả cách tôi phân biệt DAL với ORM:

Một DAL là những gì bạn tự viết, có thể bắt đầu từ một lớp chỉ gói gọn một bảng và ánh xạ các trường của nó vào các thuộc tính. ORM là mã bạn không viết hoặc cơ chế trừu tượng được suy ra từ các thuộc tính khác của lược đồ dbms của bạn, chủ yếu là PK và FK. (Đây là nơi bạn tìm hiểu xem bản tóm tắt tự động có bắt đầu bị rò rỉ hay không. Tôi thích thông báo cho họ một cách có chủ ý, nhưng đó có thể chỉ là sở thích cá nhân của tôi).

Mỗi công cụ có mục đích và tầm nhìn của nó. Tôi đã tạo ra http://www.jooq.org/ chính xác để phù hợp với nhu cầu của bạn, mặc dù iBatis có lẽ cũng là một giải pháp tốt cho bạn.

jOOQ có các tính năng ORM cơ bản, nhưng nó chủ yếu tập trung vào những thứ mà tôi đoán hầu hết các nhà phát triển cần nhất, khi cố gắng tìm ORM tốt nhất cho nhu cầu của họ:

• Tạo mã
• ràng buộc biến (đó là một nỗi đau trong JDBC)
• Trừu tượng cú pháp SQL (để tránh lỗi cú pháp)

Nhưng thường thì họ đi quá xa và cung cấp quá nhiều sự trừu tượng, bạn sẽ không nghĩ rằng họ đang chạy đua với RDBMS. Mặt khác, bạn đã chọn RDBMS chính xác vì

• nó là một nguồn dữ liệu mạnh mẽ
• SQL có thể làm nhiều việc tốt, hiệu quả (chọn lồng nhau, kết hợp, tham gia phức tạp, v.v.). Thường thì ORM không thể làm những việc này.
• bạn có thể tự xử lý các giao dịch và phiên
• bạn có các thủ tục lưu trữ và UDT

jOOQ giải quyết chính xác những điểm này. Nó sẽ thực hiện tốt như JDBC, nhưng không có sự đau đớn.

Tiến thoái lưỡng nan có nên sử dụng khung hay không là khá phổ biến trong kịch bản phát triển phần mềm hiện đại.

Điều quan trọng cần hiểu là mọi khung hoặc cách tiếp cận đều có ưu và nhược điểm - ví dụ như theo kinh nghiệm của chúng tôi, chúng tôi đã thấy rằng ORM rất hữu ích khi xử lý các giao dịch, ví dụ như thao tác chèn / cập nhật / xóa - nhưng khi tìm nạp dữ liệu phức tạp kết quả trở nên quan trọng để đánh giá hiệu suất và hiệu quả của công cụ ORM.

Ngoài ra, điều quan trọng là phải hiểu rằng không bắt buộc phải chọn một khung hoặc một cách tiếp cận và thực hiện mọi thứ trong đó. Điều chúng tôi muốn nói là chúng tôi có thể kết hợp ORM và ngôn ngữ truy vấn gốc. Nhiều khung công tác ORM cung cấp các điểm mở rộng cho plugin trong SQL gốc. Chúng ta nên cố gắng không sử dụng quá mức một khuôn khổ hoặc một cách tiếp cận. Chúng ta có thể kết hợp các khuôn khổ hoặc phương pháp nhất định và đi kèm với một giải pháp thích hợp.

Bạn có thể sử dụng ORM khi chèn, cập nhật, xóa, tạo phiên bản với mức độ đồng thời cao và bạn có thể sử dụng SQL tự nhiên để tạo báo cáo và liệt kê dài

Chìa khóa khiến ORM của tôi sử dụng thực sự bay là tạo mã. Tôi đồng ý rằng tuyến ORM không phải là nhanh nhất, về mặt hiệu suất mã. Nhưng khi bạn có một nhóm từ trung bình đến lớn, DB sẽ thay đổi nhanh chóng khả năng tái tạo các lớp và ánh xạ từ DB vì một phần của quá trình xây dựng là một điều tuyệt vời đáng chú ý, đặc biệt là khi bạn sử dụng CI. Vì vậy, mã của bạn có thể không phải là nhanh nhất, nhưng mã hóa của bạn sẽ là - Tôi biết tôi sẽ thực hiện trong hầu hết các dự án.

Đề nghị của tôi là phát triển bằng ORM trong khi Schema vẫn còn lỏng, sử dụng hồ sơ để tìm các nút thắt cổ chai, sau đó điều chỉnh các khu vực cần sử dụng Sql thô.

Một suy nghĩ khác, bộ nhớ đệm được tích hợp trong Hibernate thường có thể cải thiện hiệu suất lớn nếu được sử dụng đúng cách. Không còn phải quay lại DB để đọc dữ liệu tham khảo.

Không có giải pháp 'một công cụ phù hợp với tất cả', và điều này cũng đúng với câu hỏi 'tôi có nên sử dụng hay / m hay không? '.

Tôi sẽ nói: nếu bạn phải viết một ứng dụng / công cụ rất tập trung vào dữ liệu, không có nhiều logic khác, thì tôi sẽ sử dụng SQL đơn giản, vì SQL là ngôn ngữ dành riêng cho miền của loại ứng dụng này.

Mặt khác, nếu tôi viết một ứng dụng doanh nghiệp / doanh nghiệp chứa nhiều logic 'tên miền', thì tôi sẽ viết một mô hình lớp phong phú có thể biểu thị tên miền này bằng mã. Trong trường hợp như vậy, một người lập bản đồ OR / M có thể rất hữu ích để thực hiện thành công, vì phải mất rất nhiều mã hệ thống ống nước trong tay bạn.

Một trong những ứng dụng tôi đã phát triển là một bot IRC được viết bằng python. Các mô-đun nó sử dụng chạy trong các luồng riêng biệt, nhưng tôi chưa tìm ra cách xử lý luồng khi sử dụng sqlite. Mặc dù, điều đó có thể tốt hơn cho một câu hỏi riêng biệt.

Tôi thực sự nên đã đặt lại cả tiêu đề và câu hỏi thực tế. Tôi chưa bao giờ thực sự sử dụng DAL trước đây, bằng bất kỳ ngôn ngữ nào.

Sử dụng ORM hoạt động như SQL, nhưng cung cấp kiểm tra thời gian biên dịch và loại an toàn. Giống như yêu thích của tôi: Đối tượng tri thức dữ liệu (tiết lộ: Tôi đã viết nó)

Ví dụ:

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

Phát trực tuyến đầy đủ. Dễ dàng thiết lập (không cần ánh xạ để xác định - đọc các lược đồ hiện có của bạn). Hỗ trợ tham gia, giao dịch, truy vấn bên trong, tổng hợp, v.v ... Khá nhiều thứ bạn có thể làm trong SQL. Và đã được chứng minh từ các bộ dữ liệu khổng lồ (chuỗi thời gian tài chính) cho đến tầm thường (Android).

Tôi biết câu hỏi này rất cũ, nhưng tôi nghĩ rằng tôi sẽ đăng câu trả lời trong trường hợp có ai đó bắt gặp nó như tôi. ORM đã đi một chặng đường dài. Một số trong số họ thực sự cung cấp cho bạn tốt nhất của cả hai thế giới: làm cho sự phát triển hiệu quả hơn và duy trì hiệu suất.

Hãy xem Dữ liệu SQL ( http://sqldata.codeplex.com ). Đó là một ORM trọng lượng rất nhẹ cho c # bao gồm tất cả các cơ sở.

FYI, tôi là tác giả của Dữ liệu SQL.

Tôi muốn thêm giọng nói của mình vào điệp khúc trả lời rằng "Có một nền tảng trung gian!".

Đối với một lập trình viên ứng dụng, SQL là hỗn hợp của những thứ bạn có thể muốn kiểm soát và những thứ mà bạn gần như chắc chắn không muốn bị làm phiền khi kiểm soát.

Điều tôi luôn muốn là một lớp (gọi là DAL, ORM hoặc micro-ORM, tôi không bận tâm đến điều đó) sẽ chịu trách nhiệm về các quyết định hoàn toàn có thể dự đoán được (cách đánh vần các từ khóa SQL, khi dấu ngoặc đơn đi, khi nào để phát minh ra các bí danh cột, những cột nào sẽ tạo cho một lớp chứa hai số float và int ...), trong khi để tôi phụ trách các khía cạnh cấp cao hơn của SQL, tức là cách sắp xếp THAM GIA, tính toán phía máy chủ, Các DISTINCT, BY BY, các truy vấn vô hướng, v.v.

Vì vậy, tôi đã viết một cái gì đó làm điều này: http://quince-lib.com/

Đó là cho C ++: Tôi không biết liệu đó có phải là ngôn ngữ bạn đang sử dụng hay không, nhưng tất cả đều giống nhau, có thể rất thú vị khi thấy điều này mang một "nền tảng trung gian" trông như thế nào.