Tek bir "doğru" yol olduğunu söyleyenlere kuşku duymalısınız. Doğru yol, duruma göre değişir. CPT altyapısını kullanmanın çok sayıda kayda değer yararı vardır:
- Dashboard UI'yi ücretsiz aldınız
- Yüklemenin kullanabileceği kalıcı önbellek eklentileri dahil olmak üzere, otomatik olarak WP önbelleğe alma özelliğinden yararlanabilirsiniz.
- Otomatik olarak yazı revizyonları gibi güzellikler elde edersiniz
WP_QuerySınıfa erişim elde edersiniz , yani teorik olarak, olması muhtemel ve kayıtsız ve savunmasız ve verimsiz bir SQL yazmak zorunda kalmazsınız.- Eklentiyi dağıtmayı veya açık kaynak geliştirme için açmayı planlıyorsanız, geliştiricilerin özel gönderi türlerini ve ilişkili API işlevlerini kullanarak kendi özel öğelerinizden daha rahat olduğunu fark edebilirsiniz.
CPT API'si ile ilgili sorunlar çoğunlukla 'gönderilerin' metaforu ile yüksek derecede evli olmasından ve metaforla birlikte gelen bu veri tipinin tüm yönlerinden kaynaklanmaktadır. MySQL komut satırından çalıştırın DESCRIBE wp_posts. WP, içeriğinizin bir başlığa sahip olduğunu, (tek) bir yazarı olduğunu, yalnızca oluşturulan tarihi ve en son düzenlenen tarihi izlemeniz gerektiğini, bir deeksik olmayan alan için boş alana ihtiyacınız olduğunu post_contentvb. Varsayar . Bazı içerik türleri için iyi, ancak diğerleri için zorunlu değildir. Zaten bazı potansiyel problemler yönünde işaret ettiniz:
Bu rotaya gidersem, cpt başına fazladan alanlarım için ihtiyaç duyacağım son nokta meta alanlarının sayısı ve eğer bu işleri "zorlaştırır".
wp_postsŞemayı CPT API'siyle genişletmenin iki yolu vardır : posta sonrası ve taksonomiler. Postmeta, bir dizi çeşitli veriyi depolamak için harika olan ancak karmaşık aramalar yapmak için en iyi duruma getirilmemiş olan, eşlenmemiş anahtar-değer çiftleridir. Taksonomiler bu bakımdan biraz daha esnektir, ancak çok karmaşık aramalarınız varsa yine de birçok masraflı sorgula karşılaşırsınız. ( meta_queryVe tax_queryargümanlar ve bunların sorgu yapıcı sınıfları olsa çok güzel ve kullanışlı.)
Önerdiğiniz gibi , zaman zaman raporlar söz konusu olduğunda yalnızca bu tür "yarı karmaşık ilişkisel filtreler" yapmanız gerekiyorsa, bu mimari sizin için uygun olabilir. Filtreleri kullanıcılara göstermeye başladığınızda, JOINher zaman birçok karmaşık sorguyu ve sorguyu çalıştırmanız gerekir , işler hızlı bir şekilde elden çıkar.
İlişkiler en iyi nasıl yönetilir, özellikle çoktan çok ilişkiye sahipsem
Çoktan çoğa ilişkiler, WP dev topluluğunda uzun süredir devam eden bir bağlantı noktasıdır (bkz. Https://core.trac.wordpress.org/ticket/14513 ). Taksonomi maddelerini post_ids üzerine eşleyerek özel tablolar kullanmadan taklit edebilirsiniz (örneğin, 'P3'ün Y ile P5 arasındaki ilişkiye sahip olduğunu söyleyebilirsin' diyebiliriz. (ve verimsiz) çok hızlı. Ayrıca, CPT’leri birbirine bağlayan kendi ilişkiler tablonuzu oluşturmayı düşünebilirsiniz - yine de CPT’lerin avantajını elde edersiniz ve yalnızca tek bir DB tablosu yaratırsınız. Bu yöntemin güzel bir şekilde yürütülmüş bir sürümü için, Mesajlar 2 Mesaj eklentisi bölümüne bakın: https://wordpress.org/extend/plugins/posts-to-posts/
Dolayısıyla, sonunda, şunlara dayanarak karar vermelisiniz:
- Saklayacağınız veri türleri / türleri - nasıl "yayın" ylar?
- Gerekli olacak sorgu türleri - ne kadar karmaşık olacaklar
- Ölçek - İstediğiniz şema ne kadar karmaşık, toplam kaç nesneniz olacak ve kaç kullanıcı beklemektesiniz
Cevaplar: Eğer çok posty, çok karmaşık değil ve süper büyük ölçeklendirmek zorunda değilsiniz, CPT'ler ile gidin. Aksi takdirde kendi masalarınızı düşünün.