一月两千万业务量系统的库表设计方案，求Oracle资深人士指导

Question

小弟最近在做一个系统，月均数据量两千万

目前采用的方案是：
1、按业务状态状态分表（比如已处理的在A表，正在处理的在B表，处理错误的在C表）
原因：正在处理的数据只是一个小数据量集，需要前端快速响应（前端70%业务的业务在处理这张表），所以单独放一张表。
缺点：有好几套表，难以维护，很多业务都是在移表（插入和删除操作超级多，代码也基本在复制对像），部分业务查询会有很多union，（比如某单是否重复等）个人也觉得不太好，但是为了保证前端快速响应，还是使用这种方案。

2、按地区分区，再按月份子分区，不同的分区数据保存在不同的数据文件中
原因：不同地区之间数据没有交集，一个分区出现问题不影响其它地区的业务
缺点：增加一个地区就要手动增加一个数据文件和一套分区，很不方便。
不同地区之间的业务量完全不一样，大的就超级大，小的就非常小，分区非常不均匀。但是客户更希望这种不同地区间的互不影响

历史数据肯定有备份迁移，需要保留最近三个月的数据。

个人觉得这套方案非常的不合适，希望Oracle资深人士多提一些意见，如果一些完整方案更好，非常感谢。

Answer 1

建议采用第二个方案。
首先第一个方案不可行，不能建立“已处理的在A表，正在处理的在B表，处理错误的在C表”这样的表，否则进行增删改的时候还要进行表关联，会非常慢；
其次，用分区表是解决大数据表的最简单做法，首先是按地区分区，其次，针对数据量大的分区可以根据日期等条件进行二级分区，这样做的话存储和维护都方便。
至于楼主说的“增加一个地区就要手动增加一个数据文件和一套分区”个人不是太理解，一般一个表设计好分区就可以一直用，如果还需要手动调整，只能说当初设计的时候不合理。