关于设计表结构的困惑

[xing393939]

比如一个私信的场景，二人之间的私信在表中会产生二条记录（方便查询）。
uid，chat_uid，forbid_status，is_payed，content
101 303 1 0 hello
303 101 0 0 hello
forbid_status表示被阻止私信联系，上面可以看出101用户不能发私信给303用户。
is_payed表示是否付费过，如果is_payed=1，那么即使forbid_status=1，101用户仍然可以发私信给303。

现在我是用的一张表实现的这些，现在想着用三张表实现是否更好：
chat表
uid，chat_uid，content
forbid表
uid，chat_uid，forbid_status
payed表
uid，chat_uid，is_payed

因为chat表的记录远多于forbid表和payed表，这样可以节约存储空间。另外在判断二人能否私信的时候，也不必去查chat表了。

有必要拆分表吗，我对一些数据库的一些设计概念不是很懂，只是感觉这样会更好些。。。。

[lichao]

如果拆分能减少很多冗余数据，那就拆分

[hemingway]

必须拆分，否则就是数据冗余了。
因为forbid_status和is_payed这两个数据和其他数据没有关系。

[xing393939]

@lichao
@hemingway 谢谢，如果我想学关于数据库设计方面的规范和原则什么的，有啥好的文章或者书籍推荐啊

[hemingway]

数据库系统基础教程
http://pan.baidu.com/share/link?shareid=1639985985&uk=1409453668

[michaelbibby]

多嘴一句，is_payed 应该改为 is_paid。

[hahastudio]

首先，原来的表里，我们可以知道
uid, chat_uid → forbid_status
uid → is_paid #我猜的，也许实际情况是一可以用户只对某一用户付费而使其强制收到私信？
那么这么拆分比较好
UserToUserForbid(uid, chat_uid, forbid_status)
UserPaid(uid, is_paid)
UserToUserChatContents(uid, chat_uid, timestamp, content) #在这里加入时间戳我觉得是符合应用场景的

关于数据库的范式，BCNF，3NF，4NF用的比较多，可以看一看

[xing393939]

@michaelbibby 英语不好。。
@hahastudio 实际情况的确是一个用户只对某一用户付费而使其强制收到私信

[hahastudio]

@xing393939 那可以改成 UserToUserChatStatus(uid, chat_uid, forbid_status, paid_status)