所有 WordPress 选项都是单个选项（序列化多维数组）还是多个选项？

Question

我了解 WordPress，但现在我正在开发一个相当大且高级的 WordPress 插件。

出于这个原因，我对我的数据结构投入了很多思考。

当我还是一个初学者时，我总是习惯像这样保存它（get_option（prefix_option_name））。然后我开始使用多维数组，为每个设置部分注册 1 个，现在我通常将所有插件选项保存在 1 个大的多维数组中，如下所示：plugin_options[section][option][evt.more subs here][etc]

这确实工作得很好，而且我确实喜欢这样一个事实：我可以在 init-hook 中一次性拉出所有选项（$plugin_options = get_option('plugin_options)），这样我就可以在插件中“本地”使用 $options ， 然而...

考虑到 WordPress 已经利用瞬态来缓存（WP Cache API） get_option 调用，哪个对性能更好？尽管我的插件有很多选项，但我猜你永远无法达到长文本类型的限制（4GB 数据或其他东西），即使我将它们全部打包在一个可序列化的多维数组中？但我想从性能的角度来看最好的事情，所以简而言之，这又是我的问题：

什么是最好的（对于一个相当大和复杂的 WordPress 插件）？

1. 将所有插件选项保存为单个选项（序列化多维数组），例如。name='plugin_options[节][选项]'
2. 将每个选项选项卡和选项页面拆分为自己的选项条目，例如：section[option][etc]
3. 只需为所有插件选项添加前缀，然后将其作为单独的数据库条目，例如。插件名称_选项_1、插件名称_选项_2

我喜欢“单一插件选项”方法，但现在我很困惑，如果数组真的很大，那么从数据库获取/更新 1 个大数组是否真的是最好的方法 - 就像在一个非常大的数组中一样大而先进的插件。

我认为 3 的问题在于，使用 1 时，您只需要在一个 db 调用中获取所有选项，而在 3 中（您将每个选项保存为自身的数据库条目），您将必须查询db 用于每个特定和单独的选项。

但哪个更好：1 个针对所有选项，1 个针对每个部分，1 个针对每个单独选项（我想我的问题最终可以缩小到这个范围：D）。可序列化的“单选项”插件选项多维数组实际上会变得太大吗？是否应该分开？

期待听到您对此的意见。干杯。:-)

Answer 1

我倾向于对不相关的数据选择单独的选项。在大多数情况下，这对性能并不重要，但与组合它们相比，有显着的好处。

表现

如果该选项是自动加载的（默认情况下是自动加载的），那么使用单独的选项不会导致任何额外的数据库查询。

如果您使用 Memcache，则默认情况下对象限制为 1mb，如果您的选择超出此范围，它将绕过缓存并每次都访问数据库。

其他考虑因素

我认为 Core 的设计假设是选项将被分离，所以如果你将它们组合起来，那么你必须做额外的工作来利用 Core 为你免费提供的一些有用的东西。

例如，所有这些常见做法都很容易使用单个选项来完成，但需要额外的逻辑来将组合选项减少到目标条目：

• pre_update_option{$option_name}
• 清理回调register_setting
• 从 REST API 检索设置

这也可能是一个“鸡蛋放在一个篮子里”的问题；如果错误或某些其他因素导致意外的数据丢失，用户可能会丢失所有内容，而不仅仅是单个数据。这在实践中很少见，但我见过这种情况发生，并且造成了非常严重的破坏性影响。人们应该有备份，但很多人没有，而且我也看到备份在实践中失败。