Typecho数据库设计

Typecho的定位是单用户博客系统,wordpress的负载是可控的。
单用户系统的查询比较集中,我们可以通过部署文件缓存或者内存对象缓存来达到减轻数据库压力的目的,或者增加数据库数量来达到平滑的系统扩容,因此单用户系统设计重点在于灵活性和结构化,当我们集中的暴露系统瓶颈,从另一个方面也可以集中精力去解决它。

5张表的设计

一个blog系统需要那些元素:
文章、评论、分类、链接、用户
现在的blog还需要文件、标签、链接分类、多重分类
同时还需要将可配置选项放到一张表中。

第一阶段(11张):
1.文章表
2.评论表
3.文章分类表
4.标签表
5.链接表
6.链接分类表
7.文章与分类映射表(一对多)
8.文章与标签映射表(一对多)
9.配置表
10.用户表
11.文件表

一共11张表,虽然不是很多但是总觉得还有抽象的余地.当我们仔细观察它们之间的关系后,除了配置表和用户表之外.其它表之间的关系都可以抽象为内容与项目之间的关系(可能是一对一,可能是一对多),比如评论与分类,链接与链接分类.通过这个抽象,我们可以把剩下的表缩减为3个表,那么来看看我们的第二版数据库结构
1.内容表
2.关系表
3.项目表
4.配置表
5.用户表

项目表与内容表的对应,形成了对内容的修饰

内容与内容6张表的设计

如果你仔细分析一下上面的设计,你会发现一个隐藏的问题,那就是评论表的定义.显然评论表不可能是项目表,那么他只可能是内容表,但内容与内容之间的关系是我们以上设计中所没有定义的.观察评论与内容的关系

评论从属于内容,无法单独存在
评论与内容是多对一的关系,且一条评论只能对应于一个内容
评论的数量往往比较大,对于访问量比较大的blog,其单篇文章的评论往往要达到上百篇.

根据以上考虑,评论表应该单独形成一个表与内容区分开,且根据常规做法以及速度上的考虑,评论应该用一个保留字段保存其从属内容的主键,以便查询.那么我们的第三版数据库结构就出炉了

内容表
关系表
项目表
评论表
配置表
用户表

让我们来看看内容表可以扩展出来的类型

post(文章)
draft(草稿)
page(页面)
link(链接)
attachment(文件)
然后再来看看项目表里的类型

category(分类)
tag(标签)
link_category(链接分类)

表以及字段命名
考虑到标准化和国际化的需要,我们在表以及字段设置上应该尽量使用标准名称.而由于使用了一对多的关系映射,在可以预见的地方内容与项目之间都不可能使用联合查询,而是用多次联动查询,来取出多行关联数据.所以内容表与项目表的字段是可以重名的(在联合查询中,重名字段会被覆盖).以下是我对各数据表的命名

内容表 - contents
关系表 - relationships
项目表 - metas (meta的意思为关于什么的什么)
评论表 - comments
配置表 - options
用户表 - users

数据字典

本文链接:

https://heyzen.club/index.php/cp/197.html
1 + 1 =
快来做第一个评论的人吧~