Những hạn chế của ORM của Django là gì?

Question

Tôi đã nghe các nhà phát triển không muốn sử dụng ORM, nhưng không biết tại sao. Những thiếu sót của ORM là gì?

Answer 1

Hãy để tôi bắt đầu bằng cách nói rằng tôi hoàn toàn ủng hộ việc sử dụng ORM cho hầu hết các trường hợp đơn giản. Nó cung cấp rất nhiều tiện lợi khi làm việc với một mô hình dữ liệu rất đơn giản (quan hệ).

Nhưng, kể từ khi bạn yêu cầu những thiếu sót ...

Từ quan điểm về khái niệm của cái nhìn, một ORM không bao giờ có thể là một đại diện hiệu quả của mô hình dữ liệu cơ bản. Nó sẽ, tốt nhất, là một xấp xỉ của dữ liệu của bạn - và hầu hết thời gian, điều này là đủ.

Vấn đề là một ORM sẽ ánh xạ trên cơ sở "một lớp -> một bảng", không phải lúc nào cũng hoạt động.

Nếu bạn có mô hình dữ liệu rất phức tạp - một mô hình lý tưởng không thể được đại diện bởi một bảng DB duy nhất - bạn có thể thấy rằng bạn dành rất nhiều thời gian để chống lại ORM, thay vì làm việc bạn.

Trên cấp độ thực tế, bạn sẽ thấy rằng luôn có cách giải quyết; một số nhà phát triển sẽ tham gia hỗ trợ cho/chống lại ORM, nhưng tôi ủng hộ cách tiếp cận lai. Django hoạt động tốt cho điều này, vì bạn có thể dễ dàng thả vào SQL thô khi cần thiết. Một cái gì đó như:

Model.objects.raw("SELECT ...") 

ORM mất rất nhiều công việc trong số 99,99% các trường hợp khác, khi bạn thực hiện các hoạt động CRUD đơn giản với dữ liệu của mình.

Theo kinh nghiệm của tôi, hai lý do tốt nhất để tránh một ORM hoàn toàn là:

• Khi bạn có dữ liệu phức tạp mà thường được lấy thông qua nhiều tham gia và quy tụ. Thông thường, việc viết SQL bằng tay sẽ rõ ràng hơn.
• Hiệu suất. ORM khá giỏi trong việc xây dựng các truy vấn được tối ưu hóa, nhưng không có gì có thể cạnh tranh bằng cách viết một đoạn SQL đẹp, hiệu quả.

Nhưng khi tất cả được nói và làm, sau khi làm việc rộng rãi với Django, tôi có thể dựa vào một số lần ORM không cho phép tôi làm những gì tôi muốn.

Answer 2

Một trong những vấn đề lớn nhất mà bạn cần lưu ý là việc xây dựng thừa kế thành Django ORM là khó khăn. Về cơ bản điều này là do thực tế là (Django) các lớp ORM đang cố gắng thu hẹp khoảng cách bằng cả hai quan hệ & OO. Một điều nữa tất nhiên là nhiều khóa ngoài trường.

Một khoản phí được san bằng tại Django ORM là chúng trừu tượng hóa rất nhiều công cụ cơ sở dữ liệu viết các ứng dụng hiệu quả, khả năng mở rộng với chúng là không thể. Đối với một số loại ứng dụng - với hàng triệu lượt truy cập và các mô hình có liên quan cao - xác nhận này thường đúng.

Phần lớn các ứng dụng web không bao giờ tiếp cận những đối tượng khổng lồ như vậy và không đạt được mức độ phức tạp đó. Các ORM của Django được thiết kế để nhanh chóng nhận các dự án và giúp các nhà phát triển chuyển sang các dự án dựa trên cơ sở dữ liệu mà không đòi hỏi kiến ​​thức sâu về SQL. Khi trang Web của bạn ngày càng trở nên phổ biến và phổ biến hơn, bạn chắc chắn sẽ cần phải kiểm tra hiệu suất như được mô tả trong phần đầu tiên của bài viết này. Cuối cùng, bạn có thể cần phải bắt đầu thay thế mã hướng ORM bằng SQL thô hoặc các thủ tục được lưu trữ (đọc SQLAlchemy, v.v.).

Hạnh phúc, khả năng của ORMs của Django tiếp tục phát triển. Thư viện tổng hợp của Django V1.1 là một bước tiến quan trọng, cho phép tạo truy vấn hiệu quả trong khi vẫn cung cấp một cú pháp hướng đối tượng quen thuộc. Để linh hoạt hơn nữa, các nhà phát triển Python cũng nên xem xét SQLAlchemy, đặc biệt là cho các ứng dụng Web Python không dựa vào Django.

Answer 3

creator of SQLAlchemy's response to the question is django considered now pythonic.. Điều này cho thấy rất nhiều sự khác biệt và hiểu biết sâu sắc về hệ thống.

sqlalchemy_vs_django_db discussion in reddit

Lưu ý: Cả hai liên kết đều khá dài, sẽ mất thời gian để đọc. Tôi không viết ý chính của họ mà có thể dẫn đến sự hiểu lầm.

Answer 4

Có nhiều vấn đề khác nhau dường như nảy sinh với mọi hệ thống ánh xạ đối tượng-quan hệ, mà tôi nghĩ bài báo kinh điển là của Ted Neward, người đã mô tả chủ đề là "The Vietnam of Computer Science". (Ngoài ra, cũng có một số followup in response to comments on that post và một số nhận xét từ Jeff Atwood here của Stack Overflow.)

Ngoài ra, một vấn đề thực tế đơn giản với hệ thống ORM là rất khó để xem có bao nhiêu truy vấn (và truy vấn) đang thực sự được chạy bởi một bit nhất định của mã, mà rõ ràng có thể dẫn đến các vấn đề hiệu suất. Ở Django, sử dụng xác nhận assertNumQueries trong các thử nghiệm đơn vị của bạn thực sự giúp tránh điều này, cũng như sử dụng django-devserver, thay thế cho runserver để có thể xuất truy vấn khi chúng được thực hiện.

Answer 5

IMHO vấn đề lớn hơn với Django ORM là thiếu các khóa chính kết hợp, điều này ngăn cản tôi sử dụng một số cơ sở dữ liệu cũ với django.contrib.admin.

Tôi thích SqlAlchemy qua Django ORM, đối với các dự án mà django.contrib.admin không quan trọng, tôi có xu hướng sử dụng Flask thay vì Django.

Django 1.4 đang thêm một số công cụ "bó" đẹp vào ORM.

Answer 6

Một câu trả lời từ một fan hâm mộ Django, nhưng:

• Nếu bạn sử dụng thừa kế và truy vấn cho các lớp học phụ huynh, bạn không thể nhận trẻ em (trong khi bạn có thể với SQLAlchemy).
• Group By và Having điều khoản thực sự khó dịch bằng cách sử dụng aggregate/annotate.
• Một số truy vấn các ORM làm chỉ là ridiculously dài, và đôi khi bạn và với những thứ như model.id IN [1, 2, 3... ludicrous long list]
• Có một cách yêu cầu nguyên nơi "công cụ là trong lĩnh vực" sử dụng __contains, nhưng không phải là "lĩnh vực là thứ" . Vì không có cách di động để làm điều này trên DBMS, viết SQL nguyên liệu cho nó thực sự gây phiền nhiễu. Rất nhiều trường hợp cạnh nhỏ như thế này xuất hiện nếu ứng dụng của bạn bắt đầu phức tạp, bởi vì như @Gary Chambers cho biết, dữ liệu trong DBMS không phải lúc nào cũng khớp với mô hình OO.
• Đó là một trừu tượng và đôi khi, the abstraction leaks.

Nhưng thường xuyên hơn, những người tôi gặp mà không muốn sử dụng ORM làm điều đó vì lý do sai: trí tuệ lười biếng. Một số người sẽ không cố gắng đưa ra một thử thách công bằng vì họ biết điều gì đó và muốn dính vào nó. Và thật đáng sợ có bao nhiêu người trong số họ có thể tìm thấy trong khoa học máy tính, nơi mà một phần tốt trong công việc là theo kịp với những thứ mới.

Tất nhiên, ở một số khu vực, nó chỉ có ý nghĩa. Nhưng thường là một người có lý do chính đáng không sử dụng nó, sẽ sử dụng nó trong các trường hợp khác. Tôi chưa bao giờ gặp bất kỳ nhà khoa học máy tính nghiêm túc nào nói với tất cả, chỉ những người không sử dụng nó trong một số trường hợp, và có thể giải thích tại sao.

Và để công bằng, rất nhiều lập trình viên không phải là nhà khoa học máy tính, có nhà sinh vật học, nhà toán học, giáo viên hoặc Bob, người kế bên chỉ muốn giúp đỡ. Theo quan điểm của họ, đó là hợp lý để không dành hàng giờ để học những thứ mới khi bạn có thể làm những gì bạn muốn với hộp công cụ của bạn.