wordpress数据库表结构

默认WordPress一共有以下11个表。这里加上了默认的表前缀 wp_ 。

wp_commentmeta:存储评论的元数据
wp_comments:存储评论
wp_links:存储友情链接(Blogroll)
wp_options:存储WordPress系统选项和插件、主题配置
wp_postmeta:存储文章(包括页面、上传文件、修订)的元数据
wp_posts:存储文章(包括页面、上传文件、修订)
wp_terms:存储每个目录、标签
wp_term_relationships:存储每个文章、链接和对应分类的关系
wp_term_taxonomy:存储每个目录、标签所对应的分类
wp_usermeta:存储用户的元数据
wp_users:存储用户

在WordPress的数据库结构中,存储系统选项和插件配置的wp_options表是比较独立的结构,在后文中会提到,它采用了key-value模式存储,这样做的好处是易于拓展,各个插件都可以轻松地在这里存
储自己的配置。

post,comment,user 则是三个基本表加上拓展表的组合。以wp_users为例,wp_users已经存储了每个用户会用到的基本信息,比如 login_name、display_name、 password、email等常用信息,但如果

我们还要存储一些不常用的数据,最好的做法不是去在表后加上一列,去破坏默认的表结构,而是将数据存在wp_usermeta中。wp_usermeta这个拓展表和wp_options表有类似的结构,我们可以在这里存

储每个用户的QQ号码、手机号码、登录WordPress后台的主题选项等等。

比较难以理解的是term,即wp_terms、wp_term_relationships、wp_term_taxonomy。在WordPress的系统里,我们常见的分类有文章的分类、链接的分类,实际上还有TAG,它也是一种特殊的分类方式,

我们甚至还可以创建自己的分类方法。WordPress将所有的分类及分类方法、对应结构都记录在这三个表中。wp_terms记录了每个分类的名字以及基本信息,如本站分为“WordPress开发”、“WPCEO插件

”等,这里的分类指广义上的分类,所以每个TAG也是一个“分类”。wp_term_taxonomy记录了每个分类所归属的分类方法,如“WordPress开发”、“WPCEO插件”是文章分类(category),放置友情链

接的“我的朋友”、“我的同事”分类属于友情链接分类(link_category)。wp_term_relationships记录了每个文章(或链接)所对应的分类方法。

庆幸的是,关于term的使用,WordPress中相关函数的使用方法还是比较清晰明了,我们就没必要纠结于它的构造了。

在上文中我们已经介绍了WordPress数据库中各个表的作用,本文将继续介绍每个表中每个列的作用。WordPress官方文档已经有比较详细的表格,本文仅对常用数据进行介绍。

wp_commentmeta
meta_id:自增唯一ID
comment_id:对应评论ID
meta_key:键名
meta_value:键值

wp_comments
comment_ID:自增唯一ID
comment_post_ID:对应文章ID
comment_author:评论者
comment_author_email:评论者邮箱
comment_author_url:评论者网址
comment_author_IP:评论者IP
comment_date:评论时间
comment_date_gmt:评论时间(GMT+0时间)
comment_content:评论正文
comment_karma:未知
comment_approved:评论是否被批准
comment_agent:评论者的USER AGENT
comment_type:评论类型(pingback/普通)
comment_parent:父评论ID
user_id:评论者用户ID(不一定存在)

wp_links
link_id:自增唯一ID
link_url:链接URL
link_name:链接标题
link_image:链接图片
link_target:链接打开方式
link_description:链接描述
link_visible:是否可见(Y/N)
link_owner:添加者用户ID
link_rating:评分等级
link_updated:未知
link_rel:XFN关系
link_notes:XFN注释
link_rss:链接RSS地址

wp_options
option_id:自增唯一ID
blog_id:博客ID,用于多用户博客,默认0
option_name:键名
option_value:键值
autoload:在WordPress载入时自动载入(yes/no)

wp_postmeta
meta_id:自增唯一ID
post_id:对应文章ID
meta_key:键名
meta_value:键值

wp_posts
ID:自增唯一ID
post_author:对应作者ID
post_date:发布时间
post_date_gmt:发布时间(GMT+0时间)
post_content:正文
post_title:标题
post_excerpt:摘录
post_status:文章状态(publish/auto-draft/inherit等)
comment_status:评论状态(open/closed)
ping_status:PING状态(open/closed)
post_password:文章密码
post_name:文章缩略名
to_ping:未知
pinged:已经PING过的链接
post_modified:修改时间
post_modified_gmt:修改时间(GMT+0时间)
post_content_filtered:未知
post_parent:父文章,主要用于PAGE
guid:未知
menu_order:排序ID
post_type:文章类型(post/page等)
post_mime_type:MIME类型
comment_count:评论总数

wp_terms
term_id:分类ID
name:分类名
slug:缩略名
term_group:未知

wp_term_relationships
object_id:对应文章ID/链接ID
term_taxonomy_id:对应分类方法ID
term_order:排序

wp_term_taxonomy
term_taxonomy_id:分类方法ID
term_id:taxonomy:分类方法(category/post_tag)
description:未知
parent:所属父分类方法ID
count:文章数统计

wp_usermeta
umeta_id:自增唯一ID
user_id:对应用户ID
meta_key:键名
meta_value:键值

wp_users
ID:自增唯一ID
user_login:登录名
user_pass:密码
user_nicename:昵称
user_email:Email
user_url:网址
user_registered:注册时间
user_activation_key:激活码
user_status:用户状态
display_name:显示名称

原文地址:https://www.cnblogs.com/madcoding/p/8883861.html

时间: 2024-11-09 04:37:36

wordpress数据库表结构的相关文章

wordpress数据库表结构解析

wordpress-4.4.1.zip 安装包  SQL结构 : wp_commentmeta  :文章评论额外信息表. CREATE TABLE IF NOT EXISTS `wp_commentmeta` ( `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `comment_id` bigint(20) unsigned NOT NULL DEFAULT '0', `meta_key` varchar(255) DEFAULT N

黄聪:wordpress源码解析-数据库表结构(转)

如果是一个普通的用户,不需要了解wordpress数据库的结构.但是,如果你正在写一个插件,你应该会对wordpress如何处理它的数据和关系感兴趣.如果你已经尝试使用已经存在的wordpress api 去访问你需要的数据,但不直接访问数据库的情况下,这是不可能的,WordPress的提供WPDB的类,使这项任务变得简单. WordPress数据库的11个数据表分别是: 表名(点击表名查看详细介绍) 描述 wp_commentmeta 文章评论额外信息表 wp_comments 文章评论信息表

wordpress源码解析-数据库表结构(转)

如果是一个普通的用户,不需要了解wordpress数据库的结构.但是,如果你正在写一个插件,你应该会对wordpress如何处理它的数据和关系感兴趣.如果你已经尝试使用已经存在的wordpress api 去访问你需要的数据,但不直接访问数据库的情况下,这是不可能的,WordPress的提供WPDB的类,使这项任务变得简单. WordPress数据库的11个数据表分别是: 表名(点击表名查看详细介绍) 描述 wp_commentmeta 文章评论额外信息表 wp_comments 文章评论信息表

请设计一套图书馆借书管理系统的数据库表结构

请设计一套图书馆借书管理系统的数据库表结构:可以记录基本的用户信息.图书信息.借还书信息:数据表的个数不超过6个:请画表格描述表结构(需要说明每个字段的字段名.字段类型.字段含义描述): 在数据库设计中应: 1.保证每个用户的唯一性: 2.保证每种图书的唯一性:每种图书对应不等本数的多本图书:保证每本图书的唯一性: 3.借书信息表中,应同时考虑借书行为与还书行为,考虑借书期限: 4.保证借书信息表与用户表.图书信息表之间的参照完整性: 5.限制每个用户最大可借书的本数 6.若有新用户注册或新书入

关系型数据库表结构设计规范-浅谈(转)

数据库表结构设计规范-浅谈,为啥是浅谈呢,因为主要的观点还是来自原微信公共账号的一篇文章,稍微加了一些自己的看法. 谁来进行数据库的设计? 肯定是具体的开发工程师来进行,开发同学的话,第一业务熟悉度比较高,第二结合OO和ORM的思想,能有比较好的运用关系型数据库的特性.如果是DBA同学的话,虽然对于数据库本身了解比较多,但是对于业务了解较少,很难有比较客观的设计.但是业务上线或者运行期间,需要DBA同学能够重度的加入进来,针对一些性能点和不合理的点进行优化,同事也可以在上线前,针对SQL进行re

OSSIM主要数据库表结构

OSSIM主要数据库表结构 对于从事OSSIM开发的技术人员,最主要的需要知道OSSIM库里的多种表结构,下面举几个典型事例: /* ======== config表 ======== */ DROP TABLE IF EXISTS conf; CREATE TABLE conf ( recovery        int NOT NULL, threshold       int NOT NULL, graph_threshold int NOT NULL, bar_length_left i

Activiti数据库表结构(表详细版)

http://blog.csdn.net/hj7jay/article/details/51302829 1  Activiti数据库表结构 1.1      数据库表名说明 Activiti工作流总共包含23张数据表,所有的表名默认以“ACT_”开头. 并且表名的第二部分用两个字母表明表的用例,而这个用例也基本上跟Service API匹配. u  ACT_GE_* : “GE”代表“General”(通用),用在各种情况下: u  ACT_HI_* : “HI”代表“History”(历史)

activiti数据库表结构全貌解析

下面本人介绍一些activiti这款开源流程设计引擎的数据库表结构,首先阐述:我们刚开始接触或者使用一个新的东西(技术)时我们首先多问一下自己几个为什么?为什么activiti在工作流程领域这么流行呢?仅仅是因为开源么?实现如此强大的流程引擎,activiti底层设计是如何进行的?activiti中依赖哪些技术等?这些可能应该是那些刚接触这个开源流程引擎产品的人应该有的疑问.我们在用开源产品的都是其实应该多问自己为什么?这样才能有所进步,不是么?兴许你一时兴起,“起笔”就把一款属于你自己的开源作

开源一个适用iOS的数据库表结构更新机制的代码

将前段时间开源的代码,发布一下: ARDBConfig On the iOS, provide a database table structure update mechanism, ensure that the user in any version of the installer, the database structure to ensure adapter. (在iOS上,提供一个数据库表结构更新的机制,保证用户无论从哪个版本安装程序,数据库结构保证适配.) 如:用户A的数据库版