Ⅰ 千万级用户站内短信数据库如何设计
几条建议：
主体数据建议采用软删除
短信状态相关记录新增一张关联表记录
客户权限、地区、级别信息采用拉链表设计，需要有两个关键字段，起始和截止时间
Ⅱ 最近做一个站内信，思路是这样的，信息（发信人，收信人…）和内容两个表，请问发消息如何操作，先谢谢了
数据库的设计不是这样的
一般来说，像你这样的需求，至少要有以下几张表：
（1）信息表（2）发送情况表（3）接收情况表（4）作业控制表
Ⅲ 论坛站内信群发，数据库设计该如何优化
真正的大数据保存在 信息表中， 关联表式很小的，虽然随着系统的运行数据会很多 ！！
有两种方案解决：
1， 及时加载策略：每群发一条消息自然会往消息表中插入一条数据，这时你可以同时往关联表中插入数据。 好样的，问题来了！如果系统用户几百万，你发一条站内信，就要往关联表中插几百万条数据，这是很耗性能的！！
2，延迟加载策略：每群发一条消息自然会往消息表中插入一条数据，不要及时插入到关联表。只当用户登录站内信时， 我才将消息表中的未读消息加载进来。
Ⅳ 站内信的数据库该如何设计
主键（自动编号，用户id），message内容，日期
Ⅳ sql server2005数据库，表的设计 站内信 发件人发了一封信能在发件箱删除它， 而并不影响收件人收件箱
我们网站就有这样的功能。直接放在一个表中。表中字段有：ID号，发件人，收件人，发件时间。查看时间。内容。信件状态。发件人删除标识。收件人删除标识。
以上查询组合起来就成了。按用户名来进行匹配。如果发件人状状和收件人状态同时设置为了删除。那这条信息就可以直接从数据库删除了。
Ⅵ 站内消息系统数据表怎么设计
1) 不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之 间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表 结构的重构提供可能性。 2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封 装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个 对象要负责两个或两个以上的职责，应进行分拆。 3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所 有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保 证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。 4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。 5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N 或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。 6) 在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值 依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。 7) 在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表 是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应 由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数 据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。 8)应针 对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比 较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。 9) 尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部 署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性 时，可经过平衡考虑选用存储过程。 10)当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改 异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结 构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。 11)设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。 12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能。
Ⅶ asp.net网站怎么做站内信的群发，不是电子邮件，是通过数据库做的。求高手提供一个思路。
一个表，叫message，就是存放站内信的，结构如下：
message(id, title, content, sendID,objectID,sendTime,flag)
分别为：ID,标题，内容，发送者ID，接收者ID组(里面有多个时用逗号分隔，如果为空就是发给所有人的)，发送时间，标志(可用于隐藏，删除等操作)
如果要发送，就往这个表中插入记录就可以了。
如果要接收，首先根据ID在objectID里查找，如果objectID为空，就显示，如果不为空，再查找里面有没有这个ID，如果有就显示，没有就不显示；
如果要回复，实际上就取出当前的sendID为objectID，再把自己的用户ID当作为sendID，再插入这个表。
当然以上表结构是最基础的，这只是相思种，你也可以把表结构定义的更丰富一些
Ⅷ 关于站内消息系统的一个数据库表设计
这个可根据需求加几张表就好，
用户表，信息表，信息状态表，你提到1对1，那可能还会有多对多，这种的请最后再有一个和信息关的用户群表，
字段么可以根据需求加，如果当心改到有一个土办法，看看哪个可能有很多功能改进的表多留一些字段，如果你想字段好看，那么就多加一个附表。如果你的系统不太大，不用太当心效率的问题，正常的查询10万行的数据只要你sql不是写得太差，问题都不大的。放开手出做，你在设计的过程中就会有灵感，写流程图也会有方向。
额，如果是这样，说实在你不应该拿到这种地方来讨论，如果是30万用户的当量的话，那么做法就完全不同，你有机会处理设计这个表，那么应该明白，这种表的设计应该是从架构层面来了，如果果这一个比较热门的网站，这里涉及了负载，同步，表分区，主索引。这里还和你的用的数据库有关系，用的oracle，mysql，又或是nosql，好像nosql不太合适的样子，又或别的什么什么数据库，到了一定的数量级的时候就有必要根据数据的优优方向来设计，这边没有法说，我也不想写篇论文（主要是写不出来），好吧，前面都是废话。现在可以做的事就是1，去了解你的硬件，有几台服务器给你用，2，你是打算做什么结构的，用什么编程语言，3，了解功能需要完成的细节，这个表可就不能乱改了。最后，你的问题太坑爹了吧，你这种问题放这来怎么可能有解决方案嘛，你随便拿到哪个做这种项目的公司不报个十万八万都说不起你，还这不是一个问题。这是一个工程。。。