我应该使用自定义帖子类型还是自定义数据库表进行插件开发？

#1 楼

您应该对任何说有单一“正确”方式的人都持怀疑态度。正确的方法取决于情况。使用CPT基础结构有许多显着的好处：


您免费获得了Dashboard UI
您会自动利用WP的缓存，包括安装时安装的所有持久性缓存插件可能正在使用
，您会自动获得诸如修订本之类的好东西
，您可以访问WP_Query类，这意味着从理论上讲，您不必编写任何（或至少不多）的代码-容易出错且效率低下的SQL
如果您打算分发插件或将其打开以进行开源开发，则可能会发现开发人员更愿意使用自定义帖子类型和关联的API函数要比您自己的自定义东西

CPT API的问题主要源于以下事实：它与“帖子”的隐喻高度相关，并且该数据类型的所有方面伴随着隐喻。在MySQL命令行中，运行DESCRIBE wp_posts。 WP假定您的内容具有标题，并且具有（单个）作者，您只需要跟踪创建日期和上次编辑日期，就需要空间来放置未索引的post_content等。适用于某些内容，但不一定适用于其他内容。您已经指出了一些潜在问题的方向：


如果我走那条路线，我将需要为每个cpt分配额外字段的发布元字段数使事情变得“棘手”


有两种通过CPT API扩展wp_posts模式的方法：后元和分类法。 Postmeta是未索引的键/值对，非常适合存储大量其他数据，但根本没有针对复杂的查找进行优化。在这方面，分类法更为灵活，但是如果您的查询非常复杂，您仍将面临许多潜在的昂贵子查询。 （不过meta_query和tax_query参数及其查询构造函数类非常好用。）

如果，如您所建议的那样，您只需要在代码中执行这些“半复杂关系过滤器”如果偶尔有报告，那么此体系结构可能适合您。当您开始向用户展示过滤器时，您必须始终运行许多复杂的JOIN和子查询，这些事情很快就会失控。


如何最好地管理关系，尤其是当我有很多关系时。


多对多关系是WP开发社区中长期存在的问题（请参阅https：//core.trac.wordpress。 org / ticket / 14513）。您可以通过将分类项目映射到post_ids上来伪造它，而无需使用自定义表（例如，可以说P3具有标签“ Y-P3”，从而说出“ P3与Y到P5的关系为Y”），但这会造成混淆（效率低下）非常快。您还可以考虑创建将CPT链接在一起的自己的关系表-您仍将获得CPT的好处，并且仅创建一个数据库表即可。有关此方法的良好执行版本，请参见Posts 2 Posts插件：https://wordpress.org/extend/plugins/posts-to-posts/

因此，最后，您应该基于以下内容决定：


您将存储的数据类型-它们如何“发布”
所需的查询类型-它们将变得多么复杂
规模-所需的架构有多复杂，将拥有多少个对象以及预期有多少用户

如果答案是：非常贴切，不太复杂并且不必扩展超大尺寸，请使用CPT。否则请考虑自己的表。