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

我对编写wordpress插件还很陌生，但是我已经涉足了深层次的工作，我想确保自己在即将进行的大型项目中做得对。

我将大量地将wordpress扩展到一个相当大的Web应用程序中，并希望保持我的数据结构尽可能本地化，以依靠wordpress框架，但是我不知道创建自己的自定义数据库表是否更好或尝试使用自定义帖子类型。

我尚不知道我的所有数据，但是将有许多表（或cpt）被关联起来。我从研究中得出的“氛围”是，我应该避免使用自定义数据库表，但是我不确定如何确定最佳解决方案。

我特别关心三个方面：

• 如果我走这条路线，每个cpt我需要为我的额外字段分配的发布元字段的数量，如果这样做会使事情“棘手”
• 使用半复杂的关系过滤器获取报告的查询效率如何
• 如何最好地管理人际关系，尤其是当我有很多对许多人际关系时

有没有“正确”的方法？感谢您的输入。

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

• 您免费获得仪表板UI
• 您将自动利用WP的缓存，包括安装可能正在使用的任何持久性缓存插件。
• 您会自动获得诸如后期修订之类的好东西
• 您可以访问WP_Query该类，这意味着从理论上讲，您不必编写任何（或至少不多）可能会变得笨拙，易受攻击且效率低下的SQL
• 如果您打算分发插件或将其打开以进行开源开发，则可能会发现，与您自己的自定义内容相比，开发人员更愿意使用自定义帖子类型和相关的API函数

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

如果我走这条路线，每个cpt我需要为我的额外字段分配的发布元字段的数量，如果这样做会使事情“棘手”

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

如果按照您的建议，仅在偶发报告的情况下只需要执行此类“半复杂关系过滤器”，那么此体系结构可能适合您。当您开始向用户展示过滤器时，您就不得不一直运行许多复杂的JOINs和子查询，这样很快就会失去控制。

如何最好地管理人际关系，尤其是当我有很多对许多人际关系时

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

因此，最后，您应该根据以下内容决定：

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

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