2010-11-07 34 views
6

Tôi đang tìm kiếm PHP5 ORM hỗ trợ đầy đủ các mối quan hệ tổng hợp (nhiều cột) dựa trên các khóa chính và khóa ngoài.ORM PHP có hỗ trợ khóa chính/khóa ngoài tổng hợp

Tôi hy vọng rằng Doctrine 2 sẽ giải quyết vấn đề này nhưng không. Đó là một tính năng cơ bản trong mô hình hóa dữ liệu quan hệ nhưng không có phần mềm ORM PHP nào mà tôi biết hỗ trợ nó.

Gần đây tôi đã tìm thấy rằng SQLAlchemy có hỗ trợ đầy đủ nhưng tôi cần một cái gì đó cho PHP, không phải Python.

Trả lời

1

Doctrine 2.1 giải quyết vấn đề này hoàn toàn.

0

Từ Doctrine2 tham khảo:

thuyết 2 cho phép sử dụng hợp khóa chính. Tuy nhiên, có một số hạn chế phản đối việc sử dụng một mã định danh duy nhất. Việc sử dụng các chú thích @GeneratedValue chỉ là hỗ trợ cho đơn giản (không composite) khóa chính, có nghĩa là bạn chỉ có thể phím composite sử dụng nếu bạn tạo ra giá trị khóa chính mình trước khi gọi EntityManager # vẫn tồn tại() trên thực thể.

Để chỉ định khóa chính composite/ số nhận dạng, chỉ cần đặt chú thích @Id marker trên tất cả các trường tạo thành khóa chính.

+1

Không, thông tin của bạn là vô ích. Ngay cả Doctrine 1 cũng hỗ trợ các khóa chính kết hợp. Tôi cần quan hệ nhiều cột dựa trên khóa tổng hợp chính và khóa ngoài tổng hợp. Tài liệu tham khảo Doctrine 2 nói rằng nó không hỗ trợ ở đây: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/limitations-and-known-issues/en#limitations-and-known -issues – Daimon

+0

vâng, xin lỗi, bạn nói đúng, tôi havent thấy điều đó. Tôi đã làm việc với v1.2 – trix

+1

Tôi cũng đang sử dụng Doctrine v1.2 ngay bây giờ. Trong trường hợp này tôi tạo ra các phím thay thế xấu xí mô phỏng tính năng cần thiết ... nhưng nó phá hỏng thiết kế dữ liệu quan hệ tốt và kết thúc với hiệu suất thấp hơn (chỉ số không cần thiết) – Daimon

4

Khi bạn đang tiếp cận ứng dụng từ phối cảnh cơ sở dữ liệu giống như Doctrine2 (PHP) hoặc Hibernate (Java) mà từ đó nó được "dẫn xuất", không thích hợp. Chúng phù hợp hơn nhiều khi bạn muốn đi theo cách khác (ví dụ: "Tôi có mô hình miền OO và cần tồn tại trong một db quan hệ", không phải "Tôi có một db quan hệ và muốn một giao diện OO (được tạo ra) cho nó, mà không thực hiện bất kỳ thỏa hiệp nào ở phía cơ sở dữ liệu "). Nếu bạn sử dụng chúng mặc dù sự khác biệt quan trọng trong các phương pháp tiếp cận và bạn yêu thích lược đồ quan hệ của bạn nhiều hơn mô hình đối tượng của bạn, bạn sẽ chỉ nhận được thất vọng.

Điều thực sự quan trọng là phân biệt giữa các loại công cụ ORM khác nhau khi chúng có xu hướng tập trung vào các mô hình phát triển khác nhau.

Có thể thử Propel hoặc RedBeanPHP, có vẻ phù hợp với mô hình phát triển dựa trên cơ sở dữ liệu mà hầu như không có ánh xạ, chỉ đơn thuần là các đối tượng dữ liệu "thuần túy" và không trừu tượng. Các trường khóa ngoài chỉ được đưa vào các đối tượng trực tiếp trong các giải pháp này, v.v. để chúng có thể "hỗ trợ" tất cả nội dung tổng hợp mà bạn muốn.

Các giải pháp như Doctrine2 hoặc Hibernate không khuyến khích sử dụng các phím tổng hợp và do đó chỉ hỗ trợ chúng lên đến một mức nhất định (Hibernate đi khá xa nhưng chúng không được khuyến nghị sử dụng).

Cá nhân tôi không phải là người hâm mộ các phím tổng hợp (ngoại trừ các bảng liên kết nhiều liên kết thuần túy không có dữ liệu bổ sung) vì tôi có xu hướng tiếp cận nhiều thứ hơn từ ứng dụng/miền-mô hình/đối tượng và có các phím tổng hợp được ánh xạ tới các đối tượng thường là một nỗi đau để làm việc với, ngay cả khi công nghệ ánh xạ bên dưới hỗ trợ chúng. Các khóa thay thế (hoặc ít nhất là các khóa tự nhiên một trường) làm cho mọi thứ trở nên đơn giản hơn nhiều. Tôi không phải là một nhà quan hệ tình dục-bình thường-cơ sở dữ liệu-bình thường hóa và "hiệu suất tốt hơn" là rất có vấn đề từ quan điểm của tôi. Việc lưu một lần tham gia không thường xuyên sẽ không giúp bạn tiết kiệm nếu bạn có vấn đề về hiệu năng thực sự trong một hệ thống.

+0

Vui lòng không đề cập đến Hibernate. Nó là nhiều hơn khả năng tạo mô hình miền từ cơ sở dữ liệu, đặc biệt là các phím tổng hợp. –

+5

Cảm ơn, đó là một điểm tốt, nhưng theo quan điểm của tôi, mô hình dữ liệu quan hệ quan trọng hơn nhiều so với ứng dụng. Tôi biết các hệ thống có cơ sở dữ liệu cũ hơn 25 năm (không có thay đổi quan trọng) - và các ứng dụng của họ đã thay đổi hàng chục lần hoàn toàn. Thay đổi một ứng dụng rất dễ dàng - việc thay đổi hoặc điều chỉnh thiết kế dữ liệu xấu là rất khó hoặc đôi khi không thể thực hiện được mà không cần thêm một nửa dữ liệu. Đó là lý do tại sao tôi nghĩ rằng phát triển phần mềm nên tập trung vào dữ liệu không tập trung vào ứng dụng - và đó là lý do tại sao tôi tìm kiếm một ORM dựa trên cơ sở dữ liệu. – Daimon

+1

@ jpartogi: Trong mắt tôi, bạn không bao giờ có thể tạo ra một mô hình miền (tốt) bằng cách đảo ngược một cơ sở dữ liệu quan hệ, và nó cũng không khuyến khích sử dụng các phím tổng hợp với Hibernate. Trích dẫn từ tài liệu: "Có một khai báo thay thế cho phép truy cập vào dữ liệu cũ bằng các phím tổng hợp. Việc sử dụng nó được khuyến khích mạnh mẽ cho bất kỳ điều gì khác." Tôi biết nó có hỗ trợ mạnh mẽ cho nó nhưng chủ yếu là cho cơ sở dữ liệu di sản. – romanb

0

Bạn có thể thử số LEAP ORM, được viết bằng PHP 5. Nó có sẵn trên github tại https://github.com/spadefoot/kohana-orm-leap.

Leap ORM hỗ trợ đầy đủ các phím tổng hợp, cho cả khóa chính và khóa ngoài. Tương tự như vậy, nó hoạt động với các khóa chính không phải là số nguyên/khóa ngoài. Trong các mô hình ORM, bạn có thể tạo bí danh trường, bộ điều hợp trường và quan hệ.

Mặc dù được viết cho Kohana PHP Framework, bạn có thể dễ dàng làm cho nó hoạt động với bất kỳ khung công tác PHP nào bằng cách chỉ thêm chức năng tự động tải đơn giản cho mã của bạn. Leap hoạt động với các cơ sở dữ liệu sau: DB2, Drizzle, Firebird, MariaDB, MS SQL, MySQL, Oracle, PostgreSQL và SQLite. Nó cũng cung cấp cả trình tạo truy vấn và một nhóm kết nối cơ sở dữ liệu.

Trên trang web của ORM, có rất nhiều tốt examples and tutorials để giúp bạn hiểu cách sử dụng nó.

Các vấn đề liên quan