Nhược điểm của ánh xạ quan hệ đối tượng

Question

Tôi là một fan của ORM - Object Relational Mapping và tôi đã sử dụng nó với Rails trong một năm rưỡi qua. Trước đó, tôi sử dụng để viết các truy vấn thô bằng cách sử dụng JDBC và làm cho cơ sở dữ liệu thực hiện việc nâng hạng nặng thông qua các thủ tục lưu trữ. Với ORM, ban đầu tôi rất vui khi thực hiện các công cụ như coach.manager và manager.coaches rất đơn giản và dễ đọc.

Nhưng khi thời gian trôi qua đã có vô số các liên kết leo lên và tôi kết thúc làm a.b.c.d đã kích hoạt truy vấn theo mọi hướng, đằng sau hậu trường. Với đường ray và ruby, bộ thu gom rác đã đi hạt và mất thời gian điên rồ để tải một trang rất phức tạp liên quan đến dữ liệu tương đối ít hơn. Tôi đã phải thay thế mã phong cách ORM này bằng một thủ tục được lưu trữ đơn giản và kết quả tôi thấy là rất lớn. Một trang mất 50 giây để tải ngay chỉ mất 2 giây.

Với sự khác biệt lớn này, tôi có nên tiếp tục sử dụng ORM không? Nó là rất rõ ràng nó có overheads nghiêm trọng so với một truy vấn thô.

Nói chung, những cạm bẫy chung của việc sử dụng khung công tác ORM như Hibernate, ActiveRecord là gì?

Answer 1

Tôi nghĩ bạn đã xác định được sự cân bằng chính liên quan đến phần mềm ORM. Mỗi khi bạn thêm một lớp trừu tượng mới cố gắng cung cấp một triển khai tổng quát về một cái gì đó mà bạn sử dụng để làm bằng tay sẽ có một số mất hiệu suất/hiệu quả.

Như bạn đã lưu ý, việc di chuyển nhiều mối quan hệ như a.b.c.d có thể không hiệu quả, vì hầu hết phần mềm ORM sẽ thực hiện truy vấn cơ sở dữ liệu độc lập cho mỗi . trên đường đi. Nhưng tôi không chắc chắn điều đó có nghĩa là bạn nên loại bỏ hoàn toàn ORM. Hầu hết các giải pháp ORM (hoặc ít nhất, chắc chắn Hibernate) cho phép bạn chỉ định các truy vấn tùy chỉnh, nơi bạn có thể mang lại chính xác những gì bạn muốn trong một hoạt động cơ sở dữ liệu duy nhất. Điều này nên nhanh như SQL chuyên dụng của bạn.

Thực sự vấn đề là hiểu được lớp ORM hoạt động như thế nào, và nhận ra rằng trong khi một cái gì đó giống như a.b.c.d rất đơn giản để viết, nó làm cho lớp ORM làm như thế nào. Theo nguyên tắc chung, tôi luôn đi với cách tiếp cận đơn giản nhất có thể để bắt đầu, và sau đó viết các truy vấn được tối ưu hóa ở các khu vực có ý nghĩa/rõ ràng là cách tiếp cận đơn giản sẽ không mở rộng.

Answer 2

ORM chỉ là công cụ. Nếu bạn không sử dụng đúng cách, bạn sẽ có kết quả không tốt.

Không có gì ngăn bạn sử dụng truy vấn HQL/tiêu chí chuyên dụng, với tìm nạp tham gia hoặc dự, để trả lại thông tin mà trang của bạn phải hiển thị trong ít truy vấn nhất có thể. Điều này sẽ mất nhiều hơn hoặc ít hơn cùng một lúc như các truy vấn SQL chuyên dụng. Nhưng tất nhiên, nếu bạn chỉ nhận được tất cả mọi thứ bằng ID và điều hướng thông qua các đối tượng của bạn mà không nhận ra có bao nhiêu truy vấn nó tạo ra, nó sẽ dẫn đến thời gian tải lâu dài. Điều quan trọng là phải biết chính xác những gì ORM làm đằng sau hiện trường, và quyết định xem nó có phù hợp hay không hoặc nếu một chiến lược khác phải được áp dụng.

Answer 3

Tôi muốn nói, người ta nên sử dụng công cụ thích hợp cho các tác vụ khác nhau.

Ví dụ: đối với các hoạt động CRUD, khung ORM như Hibernate có thể tăng tốc độ phát triển và nó sẽ hoạt động tốt. Đôi khi bạn cần thực hiện một số chỉnh sửa cần thiết để đạt được hiệu suất chấp nhận được. Tôi không chắc chắn, nhiệm vụ của bạn (những gì đã 50 giây với Hibernate) không thể được thực hiện đúng với Hibernate, bởi vì bạn đã không cung cấp cho chúng tôi với các chi tiết.

Mặt khác, ví dụ hoạt động hàng loạt liên quan đến hàng trăm nghìn bản ghi không phải là loại tác vụ bạn mong đợi Hibernate sẽ làm mà không có hình phạt hiệu suất đáng kể.

Answer 4

Tôi với Petar từ bình luận của bạn về việc quyến rũ lười biếng. Giả sử bạn có một trường đầy bảng html từ đối tượng a.b.c.d. Bạn có thể tìm thấy khuôn khổ của bạn vòng vấp ngã cơ sở dữ liệu hàng ngàn lần (có thể nhiều hơn nữa). Điểm bất lợi của ORM trong trường hợp này là bạn phải đọc kỹ tài liệu. Hầu hết các khung công tác hỗ trợ vô hiệu hóa việc tìm nạp lười và thậm chí nhiều khung công tác hỗ trợ thêm logic xử lý của riêng bạn để ràng buộc tập dữ liệu.

Sự ra đời là hầu như bất kỳ ORM nào gần như chắc chắn là tốt hơn bất cứ điều gì bạn sẽ tự viết. Bạn sẽ thấy mình bị mắc kẹt với việc duy trì các thư viện khổng lồ của boilerplate hoặc tệ hơn bằng văn bản cùng một mã hơn và hơn nữa.

Answer 5

Vì nó đã được đề cập đã có, ORM chỉ là một công cụ và bạn có thể sử dụng nó eiter tốt hay xấu.

Một trong những vấn đề hiệu suất tiêu biểu nhất trong ORMs là 1 + N truy vấn vấn đề. Nó được gây ra bằng cách tải các đối tượng bổ sung cho từng đối tượng trong danh sách. Điều này được gây ra bởi mong muốn lấy các thực thể 1-to-n-mối quan hệ cho mỗi phần tử trong danh sách, giao dịch đang sử dụng các truy vấn HQL, xác định các trường trong phép chiếu hoặc đánh dấu lấy các quan hệ 1-đến-n để lười.

Bất cứ lúc nào, bạn phải biết chính xác ORM đang làm gì để đạt được hiệu suất tốt. Không hiểu những gì hoạt động được thực hiện trong nền là một cách để thiên tai (chậm, lỗi và khó phân tích mã vì không cần thiết và sai cách viết xung quanh).

Answer 6

Hiện tại chúng tôi đang điều tra để chuyển từ lớp lưu trữ dữ liệu của chính mình với việc tách đối tượng chuyển và đối tượng truy cập dữ liệu thành JPA. Chúng tôi đã sử dụng một trình tạo để tạo các TO, DAO và DDL SQL cũng như từ một số tài liệu ở định dạng docbook. Bởi tất cả các công cụ của chúng tôi từ tài liệu, cấu trúc cơ sở dữ liệu và các lớp Java được tạo ra, nơi luôn đồng bộ với một tài liệu tốt về cơ sở dữ liệu.

gì chúng tôi phát hiện cho đến nay bằng cách sử dụng JPA:

1. tài liệu tham khảo chính nước ngoài không thể được sử dụng cho hàng nhập khẩu, một số đặc biệt truy vấn và vân vân, vì họ không được đặt trong một quản lý thực thể. JPA chỉ cho phép lớp đích ở đó.
2. Quyền truy cập vào phạm vi phiên của một số người dùng khó thực hiện. Chúng tôi vẫn không có đầu mối làm thế nào để có được những người sử dụng id vào cột 'userWhoLastMadeAnUpdate' trong một số phương pháp PrePersist.
3. Something dự kiến ​​sẽ được khá dễ dàng với một ORM, cụ thể là "lớp lập bản đồ" không làm việc ở tất cả. Chúng tôi đang sử dụng HalDateTime (http://sourceforge.net/projects/haldatetime/) nội bộ. Đặc biệt là trong khách hàng. Lập bản đồ trực tiếp với JPA không phải là mặc dù HalDateTime hỗ trợ nó. Do các hạn chế JPA chúng tôi phải sử dụng hai trường trong thực thể.
4. JPA sử dụng một trong hai tệp XML để mô tả ánh xạ. Vì vậy, bạn phải xem ít nhất thành hai tệp để thậm chí hiểu mối quan hệ giữa lớp Java và cơ sở dữ liệu. Và tệp XML sẽ trở thành lớn cho các ứng dụng lớn.
5. Ngoài ra ORMs cung cấp chú thích trong lớp Java chính nó. Vì vậy, dễ dàng hơn để tìm hiểu và hiểu mối quan hệ.Nhưng nó buộc bạn để xem tất cả những thứ cơ sở dữ liệu trong lớp khách hàng (trong đó hoàn toàn phá vỡ một lớp thích hợp).
6. Bạn sẽ phải hạn chế bản thân ở gần cấu trúc cơ sở dữ liệu sạch như mọi cách có thể. Nếu không, bạn sẽ chắc chắn kết thúc bằng một loạt các truy vấn và tuyên bố của ORM.
7. Sử dụng ORM cung cấp ngôn ngữ truy vấn gần SQL chính nó (JPA có vẻ khá chấp nhận được ở đây). Ngôn ngữ gây ra ORM làm cho việc hỗ trợ một ứng dụng lớn thực sự tốn kém.