2.收件箱 包括 接收者， 发送者，信的标题，内容，时间 等等
3.短消息 包括 接收者 ，发送者 信息内容，时间，等等
我的问题是：如何建表？有两种方式 我不知道哪种是对的
1.所有用户都放到一张表里 然后把所有的邮件也放到一个表里 把所有消息都放到一张表里 也就是一共建3张表
2.所有用户都放到一张表里 然后每个用户分别建一张 邮件表 和消息表
请问哪种方法好 ？ 还有没有其他更好的方法 当然我举的例子有点简单 实际数据时很多的
8 个解决方案
#1
一般用这种。
1.所有用户都放到一张表里 然后把所有的邮件也放到一个表里 把所有消息都放到一张表里 也就是一共建3张表
1.所有用户都放到一张表里 然后把所有的邮件也放到一个表里 把所有消息都放到一张表里 也就是一共建3张表
#2
第一种
#3
当然第一种好。
#4
不建议采用第一种！！
我倒是倾向于第二种，但也并不建议采用第二种！
为什么呢？
首先：考虑到你说的数据量是很大的，那么所有的消息都放在一张表里。用户A登录的时候，需要从消息表里统计出A的消息总数，甚至还要分页查询出消息标题列表，时间列表，等等。假若B登录，还要去再统计B。
假若多个用户登录呢？其统计工作需要巨大的IO资源和CPU资源。系统响应变慢是必然结果。
其次：消息或者邮件的‘内容’字段是个长字段吧，里面存储的内容应该是很长的，而用户一般在浏览消息或者邮件列表的时候是不需要查看这些内容的，只有查看消息的时候才会去读取这部分数据，而这个查看其实是个操作很不频繁的动作。用户一次只能查看一个消息，而这个查看相对系统来说就很容易了。但是你在统计消息列表的时候，却需要将此字段一并查询才能统计，不管这部分数据你在统计列表的时候是否用到，它在消息表里，你的查询就要去检阅这个字段。这部分CPU是个浪费啦。
我的建议是：用户分表。每100个用户一张表，这100个用户的消息存储在一张消息表里，邮件存储在一张邮件表里。这样就是3张表里，新的用户存储到另外100张表里。然后；（请仔细考虑我的然后）：将消息或者邮件的‘内容’单独作为一张表，与消息或者邮件一一对应.因为在消息或者邮件列表里，这个字段的内容根本没有必要显示。当用户查看消息内容的时候再去查询‘内容’这个表。
这样的设计对系统IO和CPU的节省不是一点半点啊！
尽管这个设计有点违背三范式原则，但却是一个高效率的设计。
仅作建议，还请三思。
我倒是倾向于第二种，但也并不建议采用第二种！
为什么呢？
首先：考虑到你说的数据量是很大的，那么所有的消息都放在一张表里。用户A登录的时候，需要从消息表里统计出A的消息总数，甚至还要分页查询出消息标题列表，时间列表，等等。假若B登录，还要去再统计B。
假若多个用户登录呢？其统计工作需要巨大的IO资源和CPU资源。系统响应变慢是必然结果。
其次：消息或者邮件的‘内容’字段是个长字段吧，里面存储的内容应该是很长的，而用户一般在浏览消息或者邮件列表的时候是不需要查看这些内容的，只有查看消息的时候才会去读取这部分数据，而这个查看其实是个操作很不频繁的动作。用户一次只能查看一个消息，而这个查看相对系统来说就很容易了。但是你在统计消息列表的时候，却需要将此字段一并查询才能统计，不管这部分数据你在统计列表的时候是否用到，它在消息表里，你的查询就要去检阅这个字段。这部分CPU是个浪费啦。
我的建议是：用户分表。每100个用户一张表，这100个用户的消息存储在一张消息表里，邮件存储在一张邮件表里。这样就是3张表里，新的用户存储到另外100张表里。然后；（请仔细考虑我的然后）：将消息或者邮件的‘内容’单独作为一张表，与消息或者邮件一一对应.因为在消息或者邮件列表里，这个字段的内容根本没有必要显示。当用户查看消息内容的时候再去查询‘内容’这个表。
这样的设计对系统IO和CPU的节省不是一点半点啊！
尽管这个设计有点违背三范式原则，但却是一个高效率的设计。
仅作建议，还请三思。
#5
我猜LZ的问题是不是在这：一张用户表存储用户信息够用了，一张消息表和一张邮件表存储消息和邮件可能会数据量过大；
对这种问题我提个想法，LZ的一个用户对应一张消息表，一张邮件表，这样做我觉得可能便于查询用户信息（包括用户的消息和邮件），但这样做不太利于数据库的维护，你想想，1个用户对应一套表（2张），那么1000个用户呢？就要2000张表，这个维护起来是不是有点麻烦啊？
LZ可以尝试下这种方法：一张用户表，一套消息表，一套邮件表，这套表的生成标准用时间，也就是说如果数据量过大的话，你可以一周或一个月生成一张消息表和邮件表.这样做也有一些弊端，比如查询用户信息不太方便（尤其是在数据库端分页查询），表的维护也有一些难题，随着时间越长，表数量也越来越多，但总不能一直增长下去，你就要考虑清理掉一些早期的表，但这样就会把用户的一些消息和邮件给清理了（在用户不知情的情况下）。
对这种问题我提个想法，LZ的一个用户对应一张消息表，一张邮件表，这样做我觉得可能便于查询用户信息（包括用户的消息和邮件），但这样做不太利于数据库的维护，你想想，1个用户对应一套表（2张），那么1000个用户呢？就要2000张表，这个维护起来是不是有点麻烦啊？
LZ可以尝试下这种方法：一张用户表，一套消息表，一套邮件表，这套表的生成标准用时间，也就是说如果数据量过大的话，你可以一周或一个月生成一张消息表和邮件表.这样做也有一些弊端，比如查询用户信息不太方便（尤其是在数据库端分页查询），表的维护也有一些难题，随着时间越长，表数量也越来越多，但总不能一直增长下去，你就要考虑清理掉一些早期的表，但这样就会把用户的一些消息和邮件给清理了（在用户不知情的情况下）。
#6
第一种。
虽然可能会造成收件箱表和短消息表的记录数过于庞大，但是从用户角度考虑谁也不会没事就去翻看以前很久的消息，定期清理过期的数据，删除或者备份出来，或者提示用户短消息表只保存一定时间内的消息等等。
虽然可能会造成收件箱表和短消息表的记录数过于庞大，但是从用户角度考虑谁也不会没事就去翻看以前很久的消息，定期清理过期的数据，删除或者备份出来，或者提示用户短消息表只保存一定时间内的消息等等。
#7
还是第一种
#8
你是选择数据库维护的方便性
还是选择系统的想要速率
自己定夺吧。
最后说一句：第一种，绝对不可取。
因为，初期的维护简单特性到后来随着数据量的增大会逐渐丧失，而系统的效率却会越来越差。
还是选择系统的想要速率
自己定夺吧。
最后说一句：第一种，绝对不可取。
因为，初期的维护简单特性到后来随着数据量的增大会逐渐丧失，而系统的效率却会越来越差。
#1
一般用这种。
1.所有用户都放到一张表里 然后把所有的邮件也放到一个表里 把所有消息都放到一张表里 也就是一共建3张表
1.所有用户都放到一张表里 然后把所有的邮件也放到一个表里 把所有消息都放到一张表里 也就是一共建3张表
#2
第一种
#3
当然第一种好。
#4
不建议采用第一种！！
我倒是倾向于第二种，但也并不建议采用第二种！
为什么呢？
首先：考虑到你说的数据量是很大的，那么所有的消息都放在一张表里。用户A登录的时候，需要从消息表里统计出A的消息总数，甚至还要分页查询出消息标题列表，时间列表，等等。假若B登录，还要去再统计B。
假若多个用户登录呢？其统计工作需要巨大的IO资源和CPU资源。系统响应变慢是必然结果。
其次：消息或者邮件的‘内容’字段是个长字段吧，里面存储的内容应该是很长的，而用户一般在浏览消息或者邮件列表的时候是不需要查看这些内容的，只有查看消息的时候才会去读取这部分数据，而这个查看其实是个操作很不频繁的动作。用户一次只能查看一个消息，而这个查看相对系统来说就很容易了。但是你在统计消息列表的时候，却需要将此字段一并查询才能统计，不管这部分数据你在统计列表的时候是否用到，它在消息表里，你的查询就要去检阅这个字段。这部分CPU是个浪费啦。
我的建议是：用户分表。每100个用户一张表，这100个用户的消息存储在一张消息表里，邮件存储在一张邮件表里。这样就是3张表里，新的用户存储到另外100张表里。然后；（请仔细考虑我的然后）：将消息或者邮件的‘内容’单独作为一张表，与消息或者邮件一一对应.因为在消息或者邮件列表里，这个字段的内容根本没有必要显示。当用户查看消息内容的时候再去查询‘内容’这个表。
这样的设计对系统IO和CPU的节省不是一点半点啊！
尽管这个设计有点违背三范式原则，但却是一个高效率的设计。
仅作建议，还请三思。
我倒是倾向于第二种，但也并不建议采用第二种！
为什么呢？
首先：考虑到你说的数据量是很大的，那么所有的消息都放在一张表里。用户A登录的时候，需要从消息表里统计出A的消息总数，甚至还要分页查询出消息标题列表，时间列表，等等。假若B登录，还要去再统计B。
假若多个用户登录呢？其统计工作需要巨大的IO资源和CPU资源。系统响应变慢是必然结果。
其次：消息或者邮件的‘内容’字段是个长字段吧，里面存储的内容应该是很长的，而用户一般在浏览消息或者邮件列表的时候是不需要查看这些内容的，只有查看消息的时候才会去读取这部分数据，而这个查看其实是个操作很不频繁的动作。用户一次只能查看一个消息，而这个查看相对系统来说就很容易了。但是你在统计消息列表的时候，却需要将此字段一并查询才能统计，不管这部分数据你在统计列表的时候是否用到，它在消息表里，你的查询就要去检阅这个字段。这部分CPU是个浪费啦。
我的建议是：用户分表。每100个用户一张表，这100个用户的消息存储在一张消息表里，邮件存储在一张邮件表里。这样就是3张表里，新的用户存储到另外100张表里。然后；（请仔细考虑我的然后）：将消息或者邮件的‘内容’单独作为一张表，与消息或者邮件一一对应.因为在消息或者邮件列表里，这个字段的内容根本没有必要显示。当用户查看消息内容的时候再去查询‘内容’这个表。
这样的设计对系统IO和CPU的节省不是一点半点啊！
尽管这个设计有点违背三范式原则，但却是一个高效率的设计。
仅作建议，还请三思。
#5
我猜LZ的问题是不是在这：一张用户表存储用户信息够用了，一张消息表和一张邮件表存储消息和邮件可能会数据量过大；
对这种问题我提个想法，LZ的一个用户对应一张消息表，一张邮件表，这样做我觉得可能便于查询用户信息（包括用户的消息和邮件），但这样做不太利于数据库的维护，你想想，1个用户对应一套表（2张），那么1000个用户呢？就要2000张表，这个维护起来是不是有点麻烦啊？
LZ可以尝试下这种方法：一张用户表，一套消息表，一套邮件表，这套表的生成标准用时间，也就是说如果数据量过大的话，你可以一周或一个月生成一张消息表和邮件表.这样做也有一些弊端，比如查询用户信息不太方便（尤其是在数据库端分页查询），表的维护也有一些难题，随着时间越长，表数量也越来越多，但总不能一直增长下去，你就要考虑清理掉一些早期的表，但这样就会把用户的一些消息和邮件给清理了（在用户不知情的情况下）。
对这种问题我提个想法，LZ的一个用户对应一张消息表，一张邮件表，这样做我觉得可能便于查询用户信息（包括用户的消息和邮件），但这样做不太利于数据库的维护，你想想，1个用户对应一套表（2张），那么1000个用户呢？就要2000张表，这个维护起来是不是有点麻烦啊？
LZ可以尝试下这种方法：一张用户表，一套消息表，一套邮件表，这套表的生成标准用时间，也就是说如果数据量过大的话，你可以一周或一个月生成一张消息表和邮件表.这样做也有一些弊端，比如查询用户信息不太方便（尤其是在数据库端分页查询），表的维护也有一些难题，随着时间越长，表数量也越来越多，但总不能一直增长下去，你就要考虑清理掉一些早期的表，但这样就会把用户的一些消息和邮件给清理了（在用户不知情的情况下）。
#6
第一种。
虽然可能会造成收件箱表和短消息表的记录数过于庞大，但是从用户角度考虑谁也不会没事就去翻看以前很久的消息，定期清理过期的数据，删除或者备份出来，或者提示用户短消息表只保存一定时间内的消息等等。
虽然可能会造成收件箱表和短消息表的记录数过于庞大，但是从用户角度考虑谁也不会没事就去翻看以前很久的消息，定期清理过期的数据，删除或者备份出来，或者提示用户短消息表只保存一定时间内的消息等等。
#7
还是第一种
#8
你是选择数据库维护的方便性
还是选择系统的想要速率
自己定夺吧。
最后说一句：第一种，绝对不可取。
因为，初期的维护简单特性到后来随着数据量的增大会逐渐丧失，而系统的效率却会越来越差。
还是选择系统的想要速率
自己定夺吧。
最后说一句：第一种，绝对不可取。
因为，初期的维护简单特性到后来随着数据量的增大会逐渐丧失，而系统的效率却会越来越差。