空间换时间的数据库设计

　　我们的系统中很常会用到SMS、Email等的发送，在我们的设计中通常会创建一个Tb_outbox表，当产生数据时，插入到Tb_outbox表，由定时器去读取Tb_outbox的数据进行发送，发送完了再修改Tb_outbox的发送状态。是的，这就是通常的做法，但是当我们的SMS、Email的发送频率和数量足够大的时候，我们的系统就会出现性能、表被锁等问题。那我们如何是好呢？

　　下面的设计的一个思想就是如标题所述：空间换时间。就个人而言，我感觉这个描述更加贴切：对象的职责分离，把Insert、Update、Delete等分离在不同的表中。废话不多说，下面就来看看这个设计图：

　　Tb_NotSent_buffer：待发送短信缓存表(即时清理).

1. 　该表是为了避免应用过多对Tb_NotSent同时操作产生锁表情况。
2. 主要考虑到产生待发短信的逻辑通常会比较复杂,或者长事务。
3. 一次性将已经在buffer表里的短信insert到Tb_NotSent,这次插入没有长事务计算,由一条insert from select完成。
4. 该表并非一定用到,视乎产生待发短信的逻辑的事务复杂度,和量而定。

　　Tb_NotSent：待发送的短信(会被定时清理)

1. 会将该已经发送的短信的处理结果存储在jms消息队列里。
2. 把这些数据从Tb_NotSent copy到Tb_outbox同时,插一条记录到Tb_Sent.这样作是为了下一步删除Tb_NotSent里已经发送的信息.同时又不因为删除而锁Tb_NotSent表(应用使用)
3. 使用空间换时间的思想,减少对同一张表(Tb_outbox)的过多操作和过程时间的操作,导致锁表出现系统瓶颈。

　　Tb_outbox：存储历史记录的主表,该表需建立在独立的数据库。

1. 减少备份文件大小，可灵活调整,大大减少备份空间的需求。
2. 减少对主数据库的影响。

　　Tb_Sent：一个参照表，为删除Tb_NotSent表做基表

1. 已经发送短信(会定时清理),存放已经被网关处理的短信(发送成功或者失败)。
2. 这个表不一定要保存和Tb_NotSent一样多的字段，也许只要两个字段，那就是ID值和状态值。