Bạn nên hoài nghi về bất cứ ai nói rằng có một cách "đúng" duy nhất. Cách đúng tùy thuộc vào tình huống. Sử dụng cơ sở hạ tầng CPT có một số lợi ích đáng chú ý:
- Bạn nhận được UI Bảng điều khiển miễn phí
- Bạn tự động tận dụng bộ nhớ đệm của WP, bao gồm mọi plugin bộ nhớ cache liên tục mà cài đặt có thể đang sử dụng
- Bạn tự động nhận được quà tặng như sửa đổi bài
- Bạn có quyền truy cập vào
WP_Querylớp, điều đó có nghĩa là về mặt lý thuyết, bạn không phải viết bất kỳ (hoặc ít nhất là không nhiều) có khả năng bị lỗi và dễ bị tổn thương và không hiệu quả
- Nếu bạn dự định phân phối plugin hoặc mở nó để phát triển nguồn mở, bạn có thể thấy rằng các nhà phát triển thoải mái hơn khi sử dụng các loại bài đăng tùy chỉnh và các hàm API được liên kết so với nội dung tùy chỉnh của riêng bạn
Các vấn đề với API CPT chủ yếu xuất phát từ thực tế là nó rất được kết hợp với phép ẩn dụ của 'bài đăng' và tất cả các khía cạnh của loại dữ liệu đi kèm với phép ẩn dụ. Từ dòng lệnh MySQL, chạy DESCRIBE wp_posts. WP giả định rằng nội dung của bạn có một tiêu đề, rằng nó có một tác giả (duy nhất), bạn chỉ cần theo dõi ngày đã tạo và ngày được chỉnh sửa lần cuối, rằng bạn sẽ cần không gian cho một người không có bản quyền post_content, v.v. tốt cho một số loại nội dung, nhưng không nhất thiết cho những người khác. Bạn đã có cử chỉ theo hướng của một số vấn đề tiềm ẩn:
số lượng siêu dữ liệu bài đăng tôi sẽ cần cho các trường thêm của tôi trên mỗi cpt nếu tôi đi theo tuyến đường đó và nếu điều đó sẽ khiến mọi thứ trở nên "khó khăn"
Có hai cách để tăng wp_postslược đồ thông qua API CPT: postmeta và taxonomies. Postmeta là cặp khóa-giá trị không được lập trình, rất phù hợp để lưu trữ một loạt dữ liệu linh tinh, nhưng hoàn toàn không được tối ưu hóa để thực hiện tra cứu phức tạp. Các nguyên tắc phân loại có phần linh hoạt hơn trong vấn đề này, nhưng bạn vẫn sẽ phải đối mặt với rất nhiều câu hỏi con có khả năng tốn kém nếu bạn có những tra cứu rất phức tạp. (Tuy nhiên meta_query, các tax_queryđối số và các lớp xây dựng truy vấn của chúng rất đẹp và tiện dụng.)
Nếu, như bạn đề xuất, bạn chỉ cần thực hiện các loại "bộ lọc quan hệ bán phức tạp" này trong trường hợp báo cáo không thường xuyên, thì kiến trúc này có thể phù hợp với bạn. Đó là khi bạn bắt đầu phơi bày các bộ lọc cho người dùng, do đó bạn phải chạy nhiều câu hỏi JOINvà truy vấn phức tạp mọi lúc, mọi thứ sẽ nhanh chóng vượt qua.
Làm thế nào để quản lý tốt nhất các mối quan hệ, đặc biệt là nếu tôi có nhiều mối quan hệ
Mối quan hệ nhiều-nhiều là một điểm gắn bó lâu năm trong cộng đồng nhà phát triển WP (xem https://core.trac.wordpress.org/ticket/14513 ). Bạn có thể giả mạo nó mà không cần sử dụng các bảng tùy chỉnh bằng cách ánh xạ các mục phân loại vào post_ids (vì vậy, ví dụ, bạn có thể nói rằng 'P3 có mối quan hệ Y đến P5' bằng cách nói rằng P3 có thẻ 'Y-P3') nhưng điều này gây nhầm lẫn (và không hiệu quả) rất nhanh. Bạn cũng có thể xem xét việc tạo bảng mối quan hệ của riêng mình để liên kết các CPT với nhau - bạn vẫn nhận được lợi ích của CPT và chỉ tạo một bảng DB duy nhất. Để biết phiên bản được thực hiện độc đáo của phương pháp này, hãy xem plugin Bài viết 2 Bài viết: https://wordpress.org/extend/plugins/posts-to-posts/
Vì vậy, cuối cùng, bạn nên quyết định dựa trên:
- Các loại dữ liệu bạn sẽ lưu trữ - chúng "đăng" như thế nào
- Các loại truy vấn sẽ được yêu cầu - chúng sẽ phức tạp đến mức nào
- Tỷ lệ - lược đồ mong muốn của bạn phức tạp đến mức nào, bạn sẽ có bao nhiêu đối tượng và bạn dự đoán có bao nhiêu người dùng
Nếu câu trả lời là: Rất bưu chính, không quá phức tạp và không phải quy mô siêu lớn, hãy đi với CPT. Nếu không hãy xem xét các bảng của riêng bạn.