上一篇：SEO: 搬家，别忘了用301 - 下一篇：海底光缆修好了吗？
版权声明：可以任意转载，但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2007/01/05/wordpress-database-doc-introduction/以及本声明。
Wordpress的官方文档对数据库的结构描述得并不充分，索性自己来分析一下。首先从整体结构入手。 下面是2.0.5版的数据库结构图(E-R图)。为了节约篇幅，这里仅列出了主键和外键。 图中菱形表示1:n的关系，白色部分为1，黑色部分为n。
Wordpress共有10个表，按照功能大致分为四类。
- user: 用户信息，包括wp_users表和wp_usermeta表。
- post: 文章及评论信息，包括wp_posts、wp_postmeta、wp_comments、wp_post2cat以及wp_categories五个表。
- link: 链接信息，包括wp_links表和wp_linkcategories表。
- option: 全局设置信息，包括wp_options表。
个人认为这个数据库有两个冗余的地方。一个是wp_post2cat表中的主键rel_id，其实可以不要rel_id，而使用post_id和category_id两列作为主键； 另一个是wp_options表，option_id列为自动增长列，仅使用该列即可作为主键，而不需要option_id、blog_id、option_name三列联合做主键。
另外，表的命名规则也很有意思。基本规则总结如下：
- 保存对象的基本属性，命名为 wp_objects，使用复数(如 wp_posts，wp_comments)；
- 保存对象的扩展属性，命名为 wp_objectmeta，使用单数(如wp_postmeta，wp_usermeta)；
- 多对多关系，命名为 wp_a2b，其中a和b分别为多对多关系两端的对象名的缩写(如wp_post2cat)。
2007-01-05 23:55
关于rel_id，我还没读过wp的代码，不知道它怎么使用wp_post2cat表。这个表是n:m关系的产物，一般情况下仅在 JOIN 中使用，而不会直接被SELECT。因此没有使用 rel_id 的必要。另一方面，由于 rel_id的存在，导致(post_id,category_id)这个二元组可能会产生重复数据，这是rel_id造成的坏影响。
主键不一定要 auto_increment 的id列，两列联合起来也可以做主键。
另外wp_options表，blog_id和option_name上的索引确实有必要，但主键是没有必要的。加个UNIQUE INDEX就够了，即PRIMARY(option_id) + UNIQUE(blog_id,option_name)。
2007-01-14 01:55
btw.这张图是用 DbDesigner 画的，一个免费的软件。
对mysql数据库支持很好，可以将设计图直接转换成数据库，
也可以由数据库生成E-R图。
不过多少有些小bug，用的时候注意一点就行了。
比如建立关系时外键会覆盖原有的列名等。。。
2007-01-23 08:58
i was just about to ask which tool can draw such good diagram:)
2008-05-07 10:40
正在学数据库结构图
非常好的文章
学习了
2008-07-21 18:18
数据库设计乃是整个系统中最重要的部分，数据库设计的好坏直接影响的产品的性能、质量，本人观点是如果能够提高系统整体运行效率，适当的冗余是非常值得的，因为对大多数站点来说，用户的行为绝大部分都是浏览，所以把浏览时系统消耗的资源以及时间通过冗余转移到写入操作上来，这无疑是明智的。我们最近自主研发的一个bbs系统也运用了这一思想。不过话说回来对此贡献不大的冗余则是不该存在的，因为这会增加系统和架构的复杂度，应细细权衡……
2007-01-05 19:28
这个…
rel_id确实可以不要.但是一般的习惯是有主键的.
两列做主键?没见过.应该是两列做索引.单独的索引就够了.
option_id,blog_id,option_name的索引有必要.