这是一个创建于 4150 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如一个私信的场景，二人之间的私信在表中会产生二条记录（方便查询）。
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表了。
有必要拆分表吗，我对一些数据库的一些设计概念不是很懂，只是感觉这样会更好些。。。。
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表了。
有必要拆分表吗，我对一些数据库的一些设计概念不是很懂，只是感觉这样会更好些。。。。
 |
1
lichao 2013-07-21 18:29:59 +08:00 via iPhone  1
如果拆分能减少很多冗余数据，那就拆分
|
 |
2
hemingway 2013-07-21 18:33:57 +08:00 1
必须拆分，否则就是数据冗余了。
因为forbid_status和is_payed这两个数据和其他数据没有关系。 |
 |
3
xing393939 OP |
|
4
hemingway 2013-07-21 19:25:52 +08:00 1
|
 |
5
michaelbibby 2013-07-21 20:14:00 +08:00 1
多嘴一句，is_payed 应该改为 is_paid。
|
 |
6
hahastudio 2013-07-21 20:33:16 +08:00 1
首先，原来的表里，我们可以知道
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用的比较多，可以看一看 |
|
7
xing393939 OP |
|
8
hahastudio 2013-07-22 11:30:10 +08:00 1
@xing393939 那可以改成 UserToUserChatStatus(uid, chat_uid, forbid_status, paid_status)
|
Select Language