????以前上學的時候數據庫學的是皮毛中的皮毛，唯一的課程設計也只是跑幾個簡單得很得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、集群方案
還有當初選修的“分布式數據庫”，不知道這個概念是不是能夠活生生的用到項目中來。。。