论如何设计博客分类标签系统

本文描述了这个博客背后归档系统的设计与实现思路。

逻辑模型设计

通常博客所用的归档方式有三种：

• 按发布时间归档
• 分类体系
• 标签体系
  这三种归档体系是可以同时存在的，而且这样的设计也非常常见。
  其中按时间归档实在是Trivial，而且归档逻辑性也相对较弱，故在此略去不提。

通常分类与标签体系最大的区别在于，文章和分类是多对一的关系，而标签和文章是多对多的关系。
实际上在使用中，我发现分类确实不如标签好用。
在使用OneNote整理笔记的时候，经常出现一类很让人头疼的Delimma。比如，用Python做的可视化演示，究竟是应当放入Python分类中呢？还是放在可视化分类中呢？
避免这个问题，需要分类设计做到完全正交，然而真正能做到完全正交的分类体系又往往不甚实用……。更重要的一点是，每当我检索笔记的时候，往往是通过类似标签形式的关键词搜索去定位文章的……分类体系更是显得累赘了……

不过完全不要分类体系好不好？当然也不好，当然，多级分类应该拍扁成一级分类，这样分类就可以做成一个字段放入文章表中了。

所以在我看来，博客的归档系统，应当以标签系统为主，分类系统为辅。
分类系统必须是扁平的，不可有过多的类目，且尽量做到正交。
我的博客目前拟采用以下分类

1. INSERT INTO categories (cate_name)
2. VALUES ('未分类'), ('随笔文章'), ('生活记录'), ('工作记录'), ('文档剪藏'), ('读书笔记'), ('前端戏法'), ('后端杂技'), ('算法心得'), ('数据库'), ('部署运维'),('知识积累'), ('游戏杂谈');

而标签就会显得比较随意了。

数据模型设计

传统方法

传统上，按照数据库设计理论Blabla，应当这样设计：

1. ------------- 基础表定义 -------------
2. -- 登录信息表
3. CREATE TABLE IF NOT EXISTS login (
4. user_id SERIAL PRIMARY KEY,
5. email TEXT NOT NULL UNIQUE,
6. hashed_password TEXT NOT NULL
7. );
9. -- 用户信息表
10. CREATE TABLE IF NOT EXISTS users (
11. user_id INTEGER PRIMARY KEY REFERENCES login (user_id),
12. email TEXT NOT NULL UNIQUE,
13. name TEXT NOT NULL,
14. avatar TEXT
15. );
17. -- 博文分类表
18. CREATE TABLE IF NOT EXISTS categories (
19. cate_id SERIAL PRIMARY KEY,
20. cate_name TEXT NOT NULL UNIQUE
21. );
23. -- 博客文章表
24. CREATE TABLE IF NOT EXISTS articles (
25. article_id SERIAL PRIMARY KEY,
26. user_id INT NOT NULL REFERENCES users (user_id),
27. title TEXT NOT NULL,
28. content TEXT NOT NULL,
29. description TEXT,
30. thumb TEXT,
31. cate_id INTEGER NOT NULL REFERENCES categories (cate_id) DEFAULT 1,
32. private BOOLEAN DEFAULT FALSE,
33. ctime TIMESTAMP NOT NULL DEFAULT current_timestamp,
34. mtime TIMESTAMP NOT NULL DEFAULT current_timestamp,
35. read_cnt INT DEFAULT 0,
36. upvote_cnt INT DEFAULT 0
37. );
39. -- 标签表
40. CREATE TABLE IF NOT EXISTS tags (
41. tag_id SERIAL PRIMARY KEY,
42. tag_name TEXT NOT NULL UNIQUE
43. );
45. -- 标签映射表
46. CREATE TABLE IF NOT EXISTS tag_mapping (
47. article_id INTEGER REFERENCES articles (article_id) ON DELETE CASCADE,
48. tag_id INTEGER REFERENCES tags (tag_id),
49. PRIMARY KEY (article_id, tag_id)
50. );
52. ---------------- 复合类型定义 ----------------
53. -- 文章类型,包括文章的详细信息
54. CREATE TYPE article AS (
55. user_id INTEGER,
56. cate_id INTEGER,
57. article_id INTEGER,
58. title TEXT,
59. content TEXT,
60. description TEXT,
61. thumb TEXT,
62. private BOOLEAN,
63. ctime TIMESTAMP,
64. mtime TIMESTAMP,
65. read_cnt INTEGER,
66. upvote_cnt INTEGER,
67. cate_name TEXT,
68. email TEXT,
69. name TEXT,
70. avatar TEXT,
71. tags JSONB
72. );
74. -- 文章摘要,除了content字段外的所有信息
75. CREATE TYPE article_entry AS (
76. user_id INTEGER,
77. cate_id INTEGER,
78. article_id INTEGER,
79. title TEXT,
80. description TEXT,
81. thumb TEXT,
82. private BOOLEAN,
83. ctime TIMESTAMP,
84. mtime TIMESTAMP,
85. read_cnt INTEGER,
86. upvote_cnt INTEGER,
87. cate_name TEXT,
88. email TEXT,
89. name TEXT,
90. avatar TEXT,
91. tags JSONB
92. );
94. -- 标签信息
95. CREATE TYPE tag AS (
96. tag_id INTEGER,
97. tag_name TEXT,
98. article_cnt INTEGER,
99. articles INTEGER []
100. );
102. -- 类目信息
103. CREATE TYPE category AS (
104. cate_id INTEGER,
105. cate_name TEXT,
106. article_cnt INTEGER,
107. articles INTEGER []
108. );
110. -- 用户信息
111. CREATE TYPE user_entry AS (
112. user_id INTEGER,
113. email TEXT,
114. hashed_password TEXT,
115. nickname TEXT,
116. avatar TEXT
117. );

这样设计的好处，当时只要对映射表轻松地聚合，就可以实现查询文章所有的标签和查询标签对应的所有文章，正查倒查效率都很高。当然坏处就是特么的查个标签最后我要Join三张表……

JSON方法

事实上，如果把标签作为一个Json字段放在文章表里，就可以省却很多这类破事了。
尤其是当PostgreSQL支持JSON索引的时候，直接通过where子句筛选标签字段，同样可以实现传统方法的功能，而且不需要额外的Join了。
不过后来，我发现JSON的设计还是不给力，因为如果我想统计每个标签下面究竟挂着多少文章，JSON的设计就蛋疼了。仔细想想，关系型数据库的崛起确实是因为它的确具有优越性。当然，最后定义了视图里面，还是采用了一些JSON字段的。