Anda harus skeptis terhadap siapa pun yang mengatakan bahwa ada satu cara "benar". Cara yang benar tergantung pada situasinya. Menggunakan infrastruktur CPT memiliki sejumlah manfaat penting:
- Anda mendapatkan Dashboard UI secara gratis
- Anda secara otomatis mengambil keuntungan dari caching WP, termasuk plugins cache persisten yang instalasi mungkin gunakan
- Anda secara otomatis mendapatkan barang seperti revisi pos
- Anda mendapatkan akses ke
WP_Querykelas, yang berarti bahwa, secara teori, Anda tidak perlu menulis apa pun (atau setidaknya tidak banyak) yang kemungkinan menjadi SQL buggy dan rentan dan tidak efisien
- Jika Anda berencana mendistribusikan plugin atau membukanya untuk pengembangan sumber terbuka, Anda mungkin menemukan bahwa pengembang lebih nyaman menggunakan jenis posting khusus dan fungsi API terkait daripada hal-hal kustom Anda sendiri
Masalah dengan API CPT sebagian besar berasal dari fakta bahwa itu sangat menikah dengan metafora 'posting', dan semua aspek dari tipe data yang datang bersama dengan metafora. Dari baris perintah MySQL, jalankan DESCRIBE wp_posts. WP mengasumsikan bahwa konten Anda memiliki judul, bahwa ia memiliki (lajang) penulis, bahwa Anda hanya perlu melacak tanggal yang dibuat dan tanggal yang diedit terakhir, bahwa Anda akan memerlukan ruang untuk yang tidak terindeks post_content, dll. Ini berfungsi baik untuk beberapa jenis konten, tetapi belum tentu untuk yang lain. Anda telah menunjuk ke arah beberapa masalah potensial:
jumlah metafield pos yang akan saya perlukan untuk bidang tambahan saya per cpt jika saya pergi rute itu, dan jika itu akan membuat hal-hal "rumit"
Ada dua cara untuk menambah wp_postsskema melalui API CPT: postmeta dan taksonomi. Postmeta adalah pasangan kunci-nilai yang tidak diindeks, yang bagus untuk menyimpan banyak data, tetapi sama sekali tidak dioptimalkan untuk melakukan pencarian yang rumit. Taksonomi agak lebih fleksibel dalam hal ini, tetapi Anda masih akan menghadapi banyak subkueri yang berpotensi mahal jika Anda memiliki pencarian yang sangat kompleks. (The meta_querydan tax_queryargumen dan kelas permintaan konstruktor mereka sangat bagus dan berguna, meskipun.)
Jika, seperti yang Anda sarankan, Anda hanya perlu melakukan "filter relasional semi kompleks" seperti ini dalam kasus laporan sesekali, maka arsitektur ini mungkin baik untuk Anda. Saat Anda mulai memaparkan filter kepada pengguna, sehingga Anda harus menjalankan banyak JOINs dan subquery kompleks sepanjang waktu, hal-hal menjadi tidak terkendali dengan cepat.
bagaimana cara terbaik mengelola hubungan, terutama jika saya memiliki banyak hubungan
Hubungan banyak ke banyak adalah titik lengket lama di komunitas WP dev (lihat https://core.trac.wordpress.org/ticket/14513 ). Anda dapat memalsukannya tanpa menggunakan tabel khusus dengan memetakan item taksonomi ke post_ids (sehingga, misalnya, Anda dapat mengatakan bahwa 'P3 memiliki hubungan Y ke P5' dengan mengatakan bahwa P3 memiliki tag 'Y-P3') tetapi ini membingungkan (dan tidak efisien) dengan sangat cepat. Anda juga dapat mempertimbangkan membuat tabel hubungan Anda sendiri yang menautkan bersama CPT - Anda masih akan mendapatkan manfaat dari CPT, dan hanya akan membuat tabel DB tunggal. Untuk versi metode ini yang dijalankan dengan baik, lihat plugin Posting 2 Posting: https://wordpress.org/extend/plugins/posts-to-posts/
Jadi, pada akhirnya, Anda harus memutuskan berdasarkan:
- Jenis data yang akan Anda simpan - bagaimana "memposting" mereka?
- Jenis pertanyaan yang akan dibutuhkan - seberapa kompleks mereka
- Skala - seberapa kompleks skema yang Anda inginkan, berapa banyak objek total yang akan Anda miliki, dan berapa banyak pengguna yang Anda antisipasi
Jika jawabannya adalah: Sangat postur, tidak terlalu rumit, dan tidak harus berskala sangat besar, gunakan CPT. Kalau tidak, pertimbangkan meja Anda sendiri.
meta_queryarg juga bagus!