何时使用定制DB表或ADD_OPTION?

时间:2012-03-15 作者:Matthew Ruddy

我有一个非常直截了当的问题。什么时候数据太多而无法使用add_option, update_option, 等等,而是使用自定义DB表?

例如,如果插件使用add_option, 等等,在它开始制造问题之前,它能处理的最大值是多少?

我的一个插件用来创建自己的DB表,但它产生了很多问题,一些用户的设置无法正常工作(尤其是在基于Microsoft的托管服务器上),更多的用户觉得需要联系我并建议我使用add_option 相反我听从了他们的建议,现在插件使用了这些功能。

然而,从那以后,我在编码能力方面取得了长足的进步,并开始重新设计插件。它现在有更多的数据要用add_option. 甚至超过10000个字符,我开始怀疑它是否会引起任何问题。

2 个回复
最合适的回答,由SO网友:EAMann 整理而成

为了记录在案,我会的never 鼓励开发人员使用自定义数据库表。是的,它们很容易使用,但您将失去WordPress提供的全部数据抽象。

add_option()/update_option()/get_option() 是基本的键值函数。它们将数据存储在MySQL LONGTEXT字段中。LONGTEXT can store over 4 million characters ... 因此,10000多个字符的选项绝对是可能的。

SO网友:Boone Gorges

有时自定义数据库表是不可避免的。如果您有一个具有许多不同属性的数据类型(例如“作业”),并且您预计需要对该数据进行复杂的筛选(例如,“向我展示马里兰州所有需要<;5年经验、薪酬超过8万美元且涉及编程或设计技能的工作”),如果没有适当的索引表,几乎不可能扩展到数百万行。

因此,您的问题的答案实际上取决于您存储的数据类型。选项表适用于配置类型数据(仅以单一方式读取),但不适用于需要以多种不同方式查询的数据。

根据数据的类型,您可能会考虑注册自定义帖子类型。这是一本不错的入门读物:http://justintadlock.com/archives/2010/04/29/custom-post-types-in-wordpress. CPT可以很好地存储相当多的数据,这些数据在结构上或多或少类似于post(没有太多不同类型的元数据,不需要项到项的关系逻辑)。这在某种程度上是两全其美的:您可以像在自定义表上一样进行非常复杂的查询(通过WP\\u查询),同时可以利用WP的“数据抽象”,正如@EAMann所建议的那样。

结束