请教一个日吞吐量比较大的数据库设计思路
hi,各位，我目前在设计一个项目，感觉以后实际投入运行时可能性能不佳，想向各位咨询一下。

背景描述如下：假设一个城市可能有四五百个供应商，大一点的城市可能有八九百个甚至上千，每个供应商每十秒钟更新其状态信息，有一个状态表用于存放状态信息；对单个城市状态表的操作是每十秒钟一次更新，另外每天可能有10W次查询；

现在的设计思路是我制定了一级规则，用于控制每增加一个城市，就让程序自己生成一个该城市的状态信息表，一个城市对应一张表。

另外，状态信息仅在一分钟内有效，所以它是可以清空的。
程序基于ASP.NET+Orclare 11g开发。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

不知道这样描述是否清晰，我想向各位请教一下是否有更好的设计思路，共同讨论一下，谢谢。

------解决方案--------------------
分区表
------解决方案--------------------

探讨

分区表

------解决方案--------------------
这个表频繁更新、查询，注意索引问题，其他的也没什么
如果单表数据库比较大(理论2G以上)，可以考虑分区表
------解决方案--------------------
--按城市编码分区，每个城市一个分区
create table Partition_HashTest 
( 
pid varchar2(20),
...
) 
partition by hash(PID) 
( 
partition part_city01 tablespace dinya_space01, 
partition part_city02 tablespace dinya_space02, 
partition part_city03 tablespace dinya_space03 
) 
--建立索引

--查询时根据城市编码指定分区
select * from Partition_Test partition(part_city01) t 

------解决方案--------------------

探讨

有没有其他的思路，比如内存表之类的

------解决方案--------------------
其实城市数不多。没必要每个城市建一张表。
城市信息表。
城市当前状态表（每次最新的）
城市历史状态表（更新的明细，包含最新的）才用按月分区
---------------------------------------
其实上业务最关心的，还是最新的数据，当前状态数据量很小。很快的。
历史状态信息。通过城市ID，时间 来查询城市历史状态表