API trường so với các trường trong hook_schema


7

Ai đó có thể vui lòng giải thích lợi thế của việc sử dụng API API để tạo các trường cho một thực thể thay vì chỉ khai báo chúng trong hook_schema là giá trị không?

Đó là một chút công việc để có được tất cả các trường được xác định, phiên bản, tùy chọn, giá trị được phép và giá trị mặc định, v.v. và sau đó bạn phải xử lý getters và setters và cuối cùng gỡ cài đặt mọi thứ không đơn giản như db_delete, đặc biệt nếu bạn có các trường tham chiếu được sử dụng bởi các thực thể khác.

Câu trả lời:


7

Ưu điểm quan trọng nhất của việc sử dụng các trường, thay vì dữ liệu tùy chỉnh trong bảng tùy chỉnh là dữ liệu của bạn có tích hợp ngay lập tức với phần còn lại của hệ thống; bao gồm (nhưng không giới hạn ở):

  • Tự động tích hợp với Chế độ xem
  • Tiềm năng sử dụng EntityFieldQuerys
  • Các trường có thể được quản lý bằng UI hệ thống tiêu chuẩn, ngay cả khi được xây dựng theo mã
  • Tự động tích hợp với các tính năng
  • Có nhiều tiện ích được đóng góp có thể nâng cao giao diện người dùng của một trường (ví dụ: tiện ích Cây tham chiếu thuật ngữ
  • Không cần tải dữ liệu tùy chỉnh của bạn lên nút / thực thể trong móc tải, hệ thống trường lõi thực hiện điều đó cho bạn
  • Không cần xác định các hoạt động CRUD cho dữ liệu của bạn

Tôi chắc chắn có nhiều, nhiều hơn nữa.

Về cơ bản, nếu bạn muốn kiểm soát chi tiết về hoạt động / hiệu suất của dữ liệu bổ sung của mình thì hãy sử dụng bảng tùy chỉnh. Nếu bạn muốn hệ thống xử lý tất cả những thứ đó cho bạn, hãy sử dụng một trường. Đối với những gì đáng giá, tôi thường sử dụng một trường để lưu trữ bất kỳ dữ liệu thực thể nào trong những ngày này.


1
rất tốt cảm ơn Có lẽ một câu hỏi tốt hơn là lý do để sử dụng các trường là gì khi bạn chỉ có thể sử dụng mô-đun Entity API ( drupal.org/project/entity ) và hook_schema và hook_entity_info để lấy các trường và CRUD. Khác với chế độ xem và hiển thị với giao diện người dùng hệ thống, tôi dường như không thể xử lý tất cả các khác biệt.
Sẽ

2

Như đã đề cập trong nhận xét về câu trả lời của Clive, khi có một thực thể tùy chỉnh được xây dựng trên đầu bộ điều khiển của Entity API làm mất hiệu lực hầu hết các điểm của Clive. Bạn nhận được CRUD, thuộc tính thực thể *, bạn có thể dễ dàng làm cho thực thể của mình có thể xuất được, hỗ trợ EFQ, thậm chí tích hợp lượt xem miễn phí. Và bạn có hiệu suất tốt hơn vì dữ liệu của bạn nằm trong một bảng duy nhất và tránh mang theo các định nghĩa trường.

Tuy nhiên, vẫn có một vài lợi thế của việc sử dụng các trường:

  • Các trường hỗ trợ nhiều giá trị của mọi loại trường.
  • Bạn có thể lưu trữ các giá trị cho các ngôn ngữ khác nhau và bạn có được giao diện người dùng cho điều này với mô-đun dịch thực thể.
  • Giao diện người dùng trường, cho phép thêm các trường bổ sung vào thực thể của bạn. Vì vậy, đối với một thực thể có thể sử dụng lại, bạn có thể muốn làm cho nó có thể thực hiện được ngay cả khi bạn không tự thêm bất kỳ trường nào.

  • Được tạo dựa trên lược đồ, vì vậy bạn có thể cần điều chỉnh chúng một chút và thêm loại thích hợp (boolean, date thay vì int, v.v.).


0

Berdir và Clive hoàn toàn đúng.

Trong thực tế tôi chỉ tìm thấy một lý do không sử dụng các trường: hiệu suất cơ sở dữ liệu. Mỗi lần ghi / cập nhật của một trường gây ra hai câu lệnh INSERT. Nếu bạn có 50 trường và bạn thực hiện một nút_save () thì điều này sẽ kích hoạt 100 INSERT.

Xin lưu ý rằng điều này không quan trọng nếu bạn có vài nghìn nút và viết thư cho họ vài lần một giờ. Nhưng cập nhật 10 triệu nút trong một đợt là một câu chuyện khác. Đối với những tình huống như vậy, bạn nên suy nghĩ về một thực thể tùy chỉnh được xây dựng trên bộ điều khiển của Entity API như berdir đã đề cập hoặc xem xét một bộ lưu trữ thay thế như MongoDB .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.