论坛数据库重构方案

[JeldorPKU]

分类总结

表名	改动意见
attachments	目前一共只有30个有效附件，考虑整体删除
boardinfo
borrow	考虑删除，重新设计
calendar	删除
captcha_codes
codes	删除
downloads	删除，重新安排
draft	存储草稿，uid tid edit_time content
comments(was lzl)	将fid改为pid，识别所属楼层
mainpage	删除
messages	只保留私信，删除系统通知，转移到notifications表。rbid, rpid, rtid, ruser, rmsg都删除。
null
posts	将pid设置为全局唯一的识别变量，将正文中的各种链接进行重新处理
sign
sms	删除
test	可以删除
threads	将tid设置为全局唯一的识别变量
userinfo	增加uid来识别每个用户， 增加birthday（生日）、student_id（学号）、name（姓名）、tel（电话），删除score
group	新建 group 表
gruop_user	group 和 user 多对多关系
privilege	新建权限表
notification	新建通知表，承担原 messages 表的通知职责，原 messages 表现在只承担站内信职责

---

以下部分是之前第一次发帖的时候的内容：

这里说的只是论坛的数据库，不含其他模块。目前已经成熟的改进方案是：

• 用threads和posts两个表来存储帖子；
• 每个帖子有唯一的tid，版面也要标记，但是tid能唯一确定一个帖子；
• 用发帖时间来对帖子进行排序，去掉pid，用算法来分页排楼；
• ...
  欢迎补充。

[JeldorPKU]

上文说到_表_的概念，我是默认还要继续使用MySQL作为后台数据库的。了解NoSQL的也可以来发表一下意见～ @huxuan

[huxuan]

NoSQL暂时不考虑吧，感觉没必要，而且NoSQL下面基本也可以划归到表和列的概念，不影响表的设计。

[zhzhzoo]

排楼用时间还是 tid 大小？

[JeldorPKU]

显示的时候当然是用最后回复的时间啊～ @zhzhzoo

[huxuan]

应该至少会有两个timestamp，一个created_at，一个updated_at，按照updated_at就可以（而且我觉得我们可以考虑提供自定义的排序方案，让用户选按照什么什么排序神马的~

[JeldorPKU]

应该至少会有两个timestamp，一个created_at，一个updated_at，按照updated_at就可以（而且我觉得> 我们可以考虑提供自定义的排序方案，让用户选按照什么什么排序神马的~

1 vote

[JeldorPKU]

需要变更的数据库相关内容有：

• 原有的论坛帖子链接；
• 原有的用相对路径表示的图片链接；
• 每个楼层都用全局统一的pid来确定，bid和tid只用来分版面和主题；
• 给每个用户唯一的uid，加上封禁、履历、罚跑、学号、姓名、手机、性别、生日等字段；

[JeldorPKU]

增加的列表：

• 活动表：包括活动的ID、日期、负责人、活动主题、活动信息等； 
• 签到表：活动的ID、参与者的ID；

[zhzhzoo]

10 楼：我们这样转换吧：新 tid = 老 tid + 20000 * 老 bid，这样子就不用打一张很大很大的表了

[zhzhzoo]

11 楼：如果按 timestamp（此处用 created_at 吧） 排序和按 pid 排序结果不一样怎么办呀～

[zhzhzoo]

12 楼：嗯以及我们有些事情可以直接在老数据库上做啊～比如 uid 什么的。。。
就是给每个人加个列叫 uid，然后趁没人了赶紧赋上值。。。

[zhzhzoo]

13 楼：咳咳要不我们这样吧：把原来数据库的 sql 文件（也可以是别的别的语言写的 ddl）传到 repo 里，然后改这个文件，交 pr，和原来不一样的地方要写出来干什么的。

嗯如果真要这么干的话征求一下意见是用哪个 ddl。。。

[JeldorPKU]

@zhzhzoo 感觉这个想法不行啊，现在数据库还在不断更新……要么就得像 @ckcz123 去年那样把论坛关掉或者设为只读一段时间咯……

[zhzhzoo]

@JeldorPKU 你说哪一楼的呀～

[JeldorPKU]

@zhzhzoo 13楼……嗯……

[zhzhzoo]

@JeldorPKU 啊改文件只是表达一下思想感情，没有任何想拿去执行的意思～

[JeldorPKU]

10 楼：我们这样转换吧：新 tid = 老 tid + 20000 * 老 bid，这样子就不用打一张很大很大的表了

这只是权宜之计吧，以后帖子真的有这么多了怎么办，我还是建议重新编号，按bid, tid（bid优先）编新的tid。

11 楼：如果按 timestamp（此处用 created_at 吧） 排序和按 pid 排序结果不一样怎么办呀～

我没有太理解你的意思。我觉得pid也应该是全局的（就像现在的fid），只不过它们分别与某个tid相关联而已，就像tid与bid相关一样。随后只要按created_at排序就行，排序的时候实时生成楼层编号。

12楼赞同。

@zhzhzoo

[zhzhzoo]

10 楼：我们这样转换吧：新 tid = 老 tid + 20000 * 老 bid，这样子就不用打一张很大很大的表了

这只是权宜之计吧，以后帖子真的有这么多了怎么办，我还是建议重新编号，按bid, tid（bid优先）编新的tid。

嗯没有说清楚。。。我们分类讨论吧：
若帖子是用新论坛发的，新 tid 与 老 tid bid 无关，tid auto_increment
若帖子是用老论坛发的，新 tid = 老 tid + 20000 * 老 bid

11 楼：如果按 timestamp（此处用 created_at 吧） 排序和按 pid 排序结果不一样怎么办呀～

我没有太理解你的意思。我觉得pid也应该是全局的（就像现在的fid），只不过它们分别与某个tid相关联而已，就像tid与bid相关一样。随后只要按created_at排序就行，排序的时候实时生成楼层编号。

就是 pid 是 auto_increment，然后后发的帖子 pid 肯定比先发的帖子 pid 大，但是后发的帖子 created_at 可能比先发的帖子 created_at 小。。。
比如前两天搞了个闰秒，然后假设我们的服务器不知道有闰秒，23:59:59 直接跳到 00:00:00 了。在 00:01:02.6 有人发了个 帖子，然后过了0.5秒，这 0.5 秒内发生了两件事情：1. ntpd 对了一下时间，2. 又有人发了个帖子。这样现在的服务器往回拨了一秒，时间是 00:01:02.1。于是后发帖子那个人发帖的时间戳在 00:01:01.6 和 00:01:02.1 之间。。。

[JeldorPKU]

就是 pid 是 auto_increment，然后后发的帖子 pid 肯定比先发的帖子 pid 大，但是后发的帖子 created_at 可能比先发的帖子 created_at 小。。。

这个不是肯定的吗，created_at先发的小，pid也是啊。

若帖子是用新论坛发的，新 tid 与 老 tid bid 无关，tid auto_increment
若帖子是用老论坛发的，新 tid = 老 tid + 20000 * 老 bid

这个……我觉得新发主题的肯定有一天会赶上……还是支持把老的tid重排之后接着加新的

@zhzhzoo

[zhzhzoo]

这个……我觉得新发主题的肯定有一天会赶上……还是支持把老的tid重排之后接着加新的

嗯有点没听懂求解释。。。

[zhzhzoo]

这个不是肯定的吗，created_at先发的小，pid也是啊。

楼上解释了一下～

[JeldorPKU]

@zhzhzoo

嗯有点没听懂求解释。。。

就是说，你现在给老帖子一个很大的tid来避免重复，将来要是新发的帖子tid慢慢自增赶上了咋办？

[zhzhzoo]

@JeldorPKU 新帖子自增从老帖子最大的 tid 开始～

[JeldorPKU]

@zhzhzoo OK pid那个我想明白了……是这样，pid不是有关联的tid嘛，直接把同一个tid的楼全部搬出来，然后按pid排序就行吧，这个时候created_at应该是严格递增的了。

ps 我好像还是没有明白后发的帖子created_at会大……

[JeldorPKU]

新帖子自增从老帖子最大的 tid 开始～

OK这个意思理解了……

[zhzhzoo]

把 bid 前的系数设成 20000 是因为水版的 tid 排到 18495 了。。。。。。

[JeldorPKU]

@zhzhzoo

影响不大是不假，你家服务器一天的数据量连一万条都没有，有毛影响，你家服务器一天能漂移个一两秒，而某家的服务器一天数据量是几亿的级别，服务器一年对一次时都能保证没漂移。说的根本就不是一回事儿好不！

微笑

[JeldorPKU]

@zhzhzoo 有新的想法先不要写到wiki那里吧，过来大家讨论成熟了再放过去～

[zhzhzoo]

取消 null 表，在 threads 表 和 posts 表 里 加上 deleted 列，然后建一个表记录删除事件

[zhzhzoo]

@JeldorPKU ok～

[JeldorPKU]

对于userinfo表我有一个想法，就是不要tokentime之类的东西，每个token的有效时间到次日凌晨4点，否则会出现帖子编辑到一半挂了的情况。在0401--次日0400之间一次登录即可，期间除非手动注销，否则token一直有效。想想怎么解决签到的问题……大家有好的意见吗？

我不知道之前设计成30分钟有什么特别的意图吗？ @ckcz123

[zhzhzoo]

@JeldorPKU 直接不要 token 了吧～ 存个用户名或者 uid 什么的。。。

[zhzhzoo]

还是没搞定系统通知。。。要不我们新建个 id 叫上帝然后把系统消息都改成上帝的通知吧。。。

[zhzhzoo]

然后站内信和通知应该是两个东西所以应该放进两个表的。。。

[JeldorPKU]

还是没搞定系统通知。。。要不我们新建个 id 叫上帝然后把系统通知都改成上帝的通知吧。。。

这是几个意思？我觉得通知的东西我们可以先不加……

然后站内信和通知应该是两个东西所以应该放进两个表的。。。

站内信是sms，通知是messages

[zhzhzoo]

啊说错了。。。把系统通知都改成上帝的站内信吧。。。

sms 是短信～

[JeldorPKU]

@zhzhzoo 我觉得还是要分开的……sms直接删掉就得了。我去更新一下wiki

[JeldorPKU]

@zhzhzoo 你说的privilege表打算怎么设计？

[ckcz123]

@JeldorPKU 有效期三十分钟这想法是前上帝Geek提出来的，具体意义我也没弄太清楚，我和I2只是实现了而已。。

[ckcz123]

@zhzhzoo 上帝账号admin。
http://www.chexie.net/bbs/boardcast/ 这个是以admin身份给所有用户群发消息。（访问需要四级权限）

[JeldorPKU]

@ckcz123 要不你问问Geek吧？可能有些安全因素我们也想不到。
消息群发的功能可以保留下来，不过以私信的方式呈现。发信方依然是admin就行。

[huxuan]

关于pid，我的理解是，把thread表里按照created_at的时间戳排序，然后pid就出来了……每读一个thread，再处理相应的post，这样应该没有什么问题吧？是我考虑漏了还是？感觉你们讨论的好复杂……

[JeldorPKU]

感觉你们讨论的好复杂……

我被帅帅绕到闰秒的问题里面去了……不然没有那么多事情的……

[JeldorPKU]

我把wiki里面的内容搬到一楼了～这样讨论起来好像方便一些，有好的建议和意见就提吧～
@CAPU-ENG/developers

[zhzhzoo]

嗯我觉得不用存 token 直接 cookie 里存 uid。。。。我们可以用 https ～

[huxuan]

1）cookie本身就是可以加密的；2）https是需要证书的，证书是需要钱的……

[zhzhzoo]

2）找“北大 CA”？

[huxuan]

@zhzhzoo 我还没见识过，你可以找给我看看……

[zhzhzoo]

https://its.pku.edu.cn/certinfo/getcert.jsp 不知道有啥用。。。

[JeldorPKU]

话说group, group_user, notifications需要更详细一点的描述和设计~大家来提提方案？ @huxuan @zhzhzoo @ckcz123

[zhzhzoo]

嗯我想所谓权限，就是对用户和资源之间的动作的可不可的规定，然后我们就存用户是谁，资源是谁，动作是啥，可还是不可～

[zhzhzoo]

感觉有点麻烦的是继承的情况，而且在我们的场景下还是多重继承
比如大师兄继承了 “所有人”，“认证了的人”，“车队队员”，“车队管家”，“网络组员”，“网络鹳狸猿” 的权限。。。
然后 “所有人” “可以” “读或发” “水版的帖子”，“网络鹳狸猿” “可以” “改” “其它人类的权限”。。。。。。

[zhzhzoo]

有时候权限之间会冲突，比如哪一天我被继承了“被封禁用户”，然后
“被封禁用户” “不能” “读或发或修改” “帖子”
但是
“所有人” “可以” “读或发” “水版的帖子”
我想给权限规定个优先级什么的。。。

[zhzhzoo]

对了以及 “水版的帖子” 继承 “帖子” ～

[JeldorPKU]

我觉得这个设计可能需要等开学了咱们面谈……我没啥经验……