0

Wordpress 的数据模型通过它的“元”表（又名 wp_postmeta、wp_commentmeta、wp_usermeta）提供可扩展性。这种名称/值对链接非常灵活，并且受到 Wordpress API 的支持。庆祝它的所有充分理由，但如果您的交易中有很多扩展属性，它也会变得非常糟糕。例如，假设我有一个名为“Blood Test”的自定义帖子类型，我希望它能够捕获来自血液分析的 30-40 个不同的测量值。每次测试都使用这个 wp_postmeta 加入是否可行？可能不是。

我可以完全定制并左右构建表格，但我想知道的是，是否没有办法至少构建“80/20 规则”并拥有一个通用扩展表，该表提供静态数量的附加列放置 SQL 可搜索属性，然后以 JSON 对象的列结束，该对象将允许非 SQL 可搜索属性扩展到几乎无限量？如下图所示：

比较两个模型

我在想，通过这样做，还可以扩展 Wordpress API，这样大多数开发人员就可以在很大程度上忽略这种结构差异。像这样的东西：

注册 API 示例：

$my_meta_ext = new WP_Meta_Extension( 'post' );
$my_meta_ext->add_tran_type( 'blood-measurement' , ( 'col1' => 'total-cholesterol' , 'col2' => 
'triglycerides', 'col3' => 'etc');

使用 API 示例：

add_ext_meta ( $term_id, 'blood-measurement.total-cholesterol', $meta_value );

好的，这是我对小组的明确问题：

  1. 这有意义吗？你觉得这有什么价值吗？类似的东西是否已经以“插件”形式（或其他形式）存在？
  2. 如果您要在所有类型（也称为帖子、评论、用户等）中使用一个扩展表，您是否能够在 mySQL 中构建一个高效的索引？每种类型都有一个表会更好吗？
  3. 有没有人有任何指标——即使它们没有被完全证明——关于默认的 wordpress 扩展模型何时开始降低性能？
  4. 如果您已经做过类似的事情......在扩展模型时学到了什么重要的经验教训？这是多么复杂的任务？
4

1 回答 1

0

我把这个话题带到了伦敦的一个专业的 WordPress 工作组，虽然我们没有得到答案，但我们非常清楚地同意这种类型的解决方案将非常有价值。此外，我决定创建一个 GIT 存储库，目的是开发一个插件来解决这个问题（希望得到伦敦小组的慷慨支持，或者任何正在阅读本文并认为你可以提供帮助的人的慷慨支持）。

可以在这里找到存储库：

https://bitbucket.org/ksnyder/wp-database-extension/

请理解，此时真的只有一个想法，一个高级设计，一个接口规范，但没有真正的代码。这当然会改变，如果你愿意帮助我们完成这项工作，它会改变得更快（请注意，我没有运行分布式开发的个人经验，但你必须在某个地方学习）。

于 2012-06-13T21:03:20.743 回答