以前上学的时候数据库学的是皮毛中的皮毛，唯一的课程设计也只是跑几个简单得很得SQL语句而已。无论是数据库设计，还是SQL语句的各种经典写法和强大功能都没有怎么好好地研究过。
功能上的学习都不全面，就更不要提性能、安全和大数据量等等在实际应用中会遇到的问题勒。参与的一个项目中，就涉及到比较大量的数据量的处理和存储（当然处理大数据量就是另外一个问题勒）。加之分配给数据库所在的磁盘空间相当有限，造成了非常捉襟见肘的局面。
幻想着有朝一日可以不为这些事情烦恼，像google,sina一样，用几十上百台配置一般的机器连起来也能作为一个强壮的server。
从网上看到一些关于存储海量数据的讨论：
1、分表、分数据库
根据一定的规则把不同的数据库表分开
缺点：有一定风险，因为一旦分开存放的两个数据库表有朝一日需要“联表”操作，那么就郁闷了，而且最好是把几个数据量大的表分开，单独拎出来几个小表意义很不大，而且业务逻辑层的代码需要知道自己要处理的数据存在哪个服务器里，有一点儿奇怪。
例如：（来自ball_lei）
我现在采用的架构采用数据库群的方式，每个客户的数据单独存在一台数据库服务器上，所有的客户根据一定的规则安排存放的数据库服务器，在主数据库服务器上有一张-索引表保存客户与数据库服务器的对应关系，每台数据库服务器中用于存放这些数据的表按照月份分成12张，每张存放当月的全部客户的数据，目前计算出单台服务器-单表需要容纳9亿条数据，并且每台服务器在这种方式下可以容纳10000个客户的数据，以后客户数量增加时只需要增加数据库服务器即可。
程序逻辑，我采用业务逻辑层的概念，对外提供应用服务器接口，全部的客户端通过应用服务器接口进行业务运算，应用服务器我也采用服务器群的概念，有一个主的应用服务器，有几个副应用服务器，全部客户端只知道该主应用服务器的地址，上线时登陆主应用服务器，然后主应用服务器根据各台应用服务器的负载情况返回给客户端真正的登陆地址（副应用服务器的地址），然后客户端再登陆到上面进行业务处理，每台应用服务器都能够访问各台数据服务器进行数据提取。
问题：需要每台应用服务器都配备一个公网ip么，还是有其他的方式可以只需要一个公网ip可以给全部的服务器公用？Nat能够实现么？或者能否进行更好的负载均衡，就是客户端的各种业务都可以在不同的服务器上运算
改进：
用户规则配置应该不大，所以也可以做成配置一次Load到内存中。
如此大数据量的项目竟不用Oracle,实在让人费解。我现在的月数据量大概2.5亿，用了3台HP
SUPERDEMO,9个CUSTERMOR DB。其中一个CATALOG数据库，相当于你的客户索引。
你的插入操作很多，所以建议少建几个索引，其实一些业务完全可以在数据库中完成，通过触发器，约束和存储过程，这样性能会有大的提高。大数据的表，分区的确是必须的，当然，还需要更完善的维护计划，否则很容易，你的业务可能就会因为性能问题挂起了。
1、通过（数据库+文件)方式进行数据存储
2、集群方案
还有当初选修的“分布式数据库”，不知道这个概念是不是能够活生生的用到项目中来。。。