php - 在 Wordpress 的 post 表中创建新字段还是创建新表更好

Question

我刚开始使用 Wordpress，不知道要选择什么解决方案。

我必须在 Wordpress 的帖子表中存储超过 200.000 个条目(书籍、CD 等)。这些条目中的每一个都有大约 20 个不同的字段需要填充。

因此，我认为我必须向 posts 表添加新字段以便存储数据。

我正在使用 ACF 自定义字段插件来执行此操作，但我可以看到自定义字段未存储在与发布表相同的表中。它被存储在类别的 wp_options 表和帖子的 postmeta 表中，对于每个要填充的字段，它将在这些表中创建 2 行。

因此，如果我在这个 wp_postmeta 表中保存 20 个字段 X 2 行 X 200.000 个条目，它将使 8.000.000 行通过(可能对性能来说不是那么好)。

使用 Wordpress 完成此任务的最佳方法是什么？

• 创建一个新表？ (我不会利用常规的帖子功能和缓存可能性)

• 向 post 表添加新字段？ (是否兼容WP升级？)

• 使用 postmeta/option 表？ (在这种情况下性能如何？)并继续使用此解决方案？

非常感谢您的帮助

Answer 1

您列出的每种方法都各有利弊:

---

Create a new table ? (I'll not take benefit of the regular post features and cache possibilities)

优点:性能
缺点:灵 active 、功能

灵 active 通过为每个字段创建一个包含列的表格，您会失去灵 active 。与仅使用元数据相比，添加新字段更加困难。对于具有大量行的表，添加或删除列是一项昂贵的操作，因此如果您需要经常修改架构，这可能不是正确的方法。

功能 使用这种方法，您将无法利用内置方法与元数据进行交互(例如 get_post_meta)。您还将很难根据元数据查询帖子。您仍然可以缓存您的数据，但您必须手动进行。据我所知，您将无法通过这种方法继续使用 ACF。

性能 从积极的方面来说，将每个字段作为单独表格中的一列可以让您更好地为数据编制索引。这是否对您有利取决于您需要运行的查询。

---

Use postmeta/option tables ? (what about performances in this case ?) and go ahead with this solution ?

缺点:灵 active 、功能
优点:性能

显然，如果您坚持使用处理元数据的默认方法，您可以继续使用所有内置功能与该数据进行交互。您还可以在不更改表结构的情况下添加或删除元字段。

关于性能，您将无法像使用单独的表那样创建索引来提高查询性能。如果您的查询不能利用 postmeta 表上的索引，这只是一个严重的问题。

请注意，wp_postmeta 在 post_id 和 meta_key 上有索引，但在 meta_value 上没有索引。这意味着如果您根据元值查找记录并且有很多行共享相同的元键，数据库必须查看所有具有特定元键的行以找到具有元键的行您正在寻找的值(value)。

So if I save 20 fields X 2 lines X 200.000 entries in this wp_postmeta table, it will make 8.000.000 lines to go through

根据您的查询，这可能不是一个严重的问题。正如我之前提到的，postmeta 表在 post_id 上有一个索引，所以如果您只是通过 post_id 查找元条目，这不是一个严重的问题。

只要您的查询可以利用索引，800 万行对 MySQL 来说不是问题。

如果您只是根据 post_id 索引进行查询，那不是问题。就内存而言，无论使用哪种方法，您都将需要大致相同的内存量。

---

Add new fields to the post table ? (will it be compatible with upgrade of WP ?)

这种方法与创建单独的表几乎相同:

• 您将更有能力通过编制索引来提高性能你的帖子表
• 您将无法使用内置功能用于与元数据交互
• 添加和删除字段将更加困难

我认为这不会导致升级 WordPress 时出现问题。即使升级包括对 wp_posts 表的修改，拥有额外的列也不应该导致问题。在生产升级之前，我肯定会在暂存环境中测试升级。

一般来说，我认为最好避免修改核心 WordPress 功能，包括修改默认表结构。与使用单独的表相比，这种方法不会有任何显着的性能优势，因此我认为最好采用另一种方式。