WordPress的可拓展性初探(一)

作者:西瓜玩偶(racnil070512 at hotmail dot com) WordPress是一个时下非常流行的网络信息发布平台,它的特性之一便是极强的可拓展性。然而在这样一个工程中,它的可拓展性是从何而来的呢?下面的篇幅尝试从两个方面简单介绍WordPress的可拓展性。这两个方面不仅可以帮助我们编写WordPress的插件,同样可以帮助我们设计具有可拓展性的架构。 1. 数据库 在原版WordPress中,每一篇文章有哪些元信息(meta-data)是已经定好了的,例如一篇文章会有“作者”、“标题”、“发布时间”、“文章内容”等。这些元信息会直接体现在数据表的结构(schema)上。例如,存放文章的表中,就会有诸如“post_author”、“post_title”、“post_date”、“post_content”等列。 但是作为插件来说,我们不可避免地要为文章添加元信息。例如发布优惠券的插件需要记录优惠码、需要记录过期时间,地图插件需要记录经纬度坐标等等。元信息是灵活的,可是数据表的结构一旦定下就很难修改。那么我们怎样做才可以实现灵活的数据表结构呢? 我们可以尝试使用行列转换的思路,把原来表中的行转换成列,把原来表中的列转换成行。 在WordPress中有一个表专门用于存储文章的元信息,名称叫做 wp_postmeta 。它只有四列,分别为 meta_id 、 post_id 、 meta_key 、 meta_value 。其中 meta_id 只是一行记录唯一的ID, post_id 表示该记录属于哪一篇文章, meta_key 为元信息的名称, meta_value 为元信息的值。 下面我们用记录地理位置信息中的经纬度举一个例子。我们需要给文章存储 latitude 和 longitude 这两个信息,首先我们需要知道,我们文章的 post_id 是多少,这是可以从 wp_posts 数据表中获取的。接下来,我们要向 wp_postmeta 中添加两条记录,分别存储精度和纬度。下面以添加纬度为例(添加经度的方法类似): INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES (<实际的文章ID>, "latitude", <实际的纬度>); 我们可以从中发现,我们并没有对数据表的结构进行任何改动,而只是向一个表中添加了信息,就达成了扩展元信息类型的目的。 需要读取元信息的思路也很简单,只要通过 post_id 在 wp_postmeta 中找到相应的记录,并且再次根据 meta_key 进行筛选就可以了。下面举例获取纬度: SELECT meta_value FROM wp_postmeta WHERE post_id=<实际的文章ID> and meta_key="latitude"; 如果要同时获取多个信息,这样写比较紧凑: SELECT MAX(CASE WHEN pm.meta_key='latitude' THEN pm.meta_value END) AS latitude, MAX(CASE WHEN pm.meta_key='longitude' THEN pm.meta_value END) AS longitude FROM wp_posts as p, wp_postmeta as pm WHERE p.ID=pm.post_id AND p.ID=<实际的文章ID> GROUP BY p.ID; 虽然这样的设计可以极大地提高数据库的可拓展性,但是同样它也带来了一些问题: 首当其冲的是效率问题,因为这样在存储一篇文章时,就不可避免地要向两个表中添加信息,查询时也要牵扯到两个表的结合,会拖慢数据库的执行效率。 其次是类型检查,一般情况下,表中每一列都有其数据类型,在向表中插入数据时,SQL会依据数据类型对其进行检查,如果采用上面的方式,那么 meta_value 只能为字符串类型,这样从某种程度降低了数据的可靠程度。 最后是数据库结构检查,一般情况下,我们可以利用 NOT NULL 来规定某一列必须有一个值,而使用上面提到的方式,就必须由Web应用程序来进行这样的检查了。 综上所述,利用这样的方式,我们确实可以提高数据库的可拓展性,但是可拓展性也不可避免地带来一些小问题。所以我们需要根据工程的具体需求,灵活地应用这种方式。 (未完待续)

原文发布于微信公众号 - php(phpdaily)

原文发表时间:2016-03-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据之美

Hive 常见问题与技巧【Updating】

1Q: 是否有像类似于phpmyadmin一样的hive查询客户端,能以界面的方式查询hive语句和导出数据 A: 有的,客户端的话可以使用squirre...

1917
来自专栏抠抠空间

MySQL 之 视图、触发器、存储过程、函数、事物与数据库锁

浏览目录: 1.视图 2.触发器 3.存储过程 4.函数 5.事物 6.数据库锁 7.数据库备份 1.视图 视图:是一个虚拟表,其内容由查询定义。同真实的表...

3267
来自专栏数据和云

自相矛盾:Null is Not Null引发的成本误区

黄玮(Fuyuncat) 资深Oracle DBA,个人网www.HelloDBA.com,致力于数据库底层技术的研究,其作品获得广大同行的高度评价. 在SQL...

2824
来自专栏代码世界

MYSQL之视图、触发器、存储过程、函数、事物、数据库锁和数据库备份

一、视图 -- view 视图:是一个虚报表,其内容由查询定义。同真实的表一样,视图包含一系列带有名称的列和行数据。 视图有如下特点:   1.视图的列可以来自...

3548
来自专栏数据和云

案发现场:被注入的软件及 ORA-600 16703 灾难的恢复

最近帮助一个客户恢复数据库,遇到了如下这个问题。让我们再一次惊醒于数据安全,如果不做好防范,问题总是会来得猝不及防。

1193
来自专栏杨建荣的学习笔记

基于时间点的不完全恢复的例子(r6笔记第9天)

说到不完全恢复,一般有三种场景,基于时间点的不完全恢复,基于scn的不完全恢复,基于cancel的不完全恢复。 三种情况都是不完全恢复采用的方式,而不完全恢复都...

2625
来自专栏学习有记

SQL Server索引简介:SQL Server索引进阶 Level 1

1374
来自专栏杨建荣的学习笔记

关于查看dba_data_files的一个小问题(r7笔记第72天)

今天帮一个朋友看一个pl/sql的问题,他已经钻到一个死胡同里列,可能明眼人一看就知道哪里有问题,但是当局者迷,所以我抽空看了一下这个pl/sql块。 pl/s...

3535
来自专栏数据和云

查看SQL执行计划的方法及优劣

作者 | 胡佳伟:云和恩墨技术工程师,有多年数据库优化经验,在一线执行过多个包括通信、保险等行业的优化项目。

892
来自专栏数据库

关于女神SQLite的疑惑(2)

还是女神SQLite的话题,继续讨论有关她的种种常见疑惑。 1.问:女神SQLite是线程安全的吗? 1.答:SQLite是线程安全的,这点确凿无疑。但我要补充...

1898

扫码关注云+社区