在設計資料庫時，選擇正確的資料型別，往往可以避免很多的問題，正確理解資料庫的型別，對於儲存空間規劃，應用效能調整都會很有幫助，下文中將對這些資料型別進行詳細的講解。
1、char
定長格式字串，在資料庫中儲存時不足位數填補空格，不建議使用，會帶來不必要的麻煩
a、字串比較的時候，如果不注意（char不足位補空格）會帶來錯誤
b、字串比較的時候，如果用trim函式，這樣該字段上的索引就失效（有時候會帶來嚴重效能問題）
c、浪費儲存空間
2、varchar2/varchar
不定長格式字串，對於4000位元組以內的字串，建議都用該型別
b、充分利用儲存空間
3、long/long raw
oracle已經廢棄，只是為了向下相容保留著，應該全部公升級到lob
long型別有很多限制
a、表中只能有一列long型別
b、long型別不支援分布式事務
c、太多的查詢不能在long上使用了
4、number
定義number的方法：number(p,s)
其中p，s都是可選的：
a、p代表精度，預設為38
b、s代表小數字數，取值範圍-84~127，預設取值要看是否指定了p，如果制定了p，預設s為0，如果沒有指定p，預設取最大值。
幾個例子：
a、 number(5,0)=number(5) 取值範圍99999～-99999
b、 number(5,2) 取值範圍999.99～-999.99
注意：其中的整數字數只有3位，小數字數有2位，按照如下方法計算：
整數字數<=p-s
小數字數<=s
如果插入123.555儲存在資料庫中變成123.56 (在小數的第三位上四捨五入)，如果插入999.999，資料庫就要拋錯。
c、 number(5,-2) 取值範圍9999900～-9999900 （整數字數<=p-s，沒有小數字數）
如果插入9999949儲存在資料庫中變成9999900（在整數的第二位上四捨五入），如果插入9999950，資料庫就要拋錯。
其他的數值型別都是number的衍生，底層都是number，比如integer/int完全對映到number(38)
效能相關：number是一種軟實現的型別，如果需要對number做複雜的運算，建議先用cast內建函式轉換number為浮點數型別
另外需要注意的一點是：number是變長型別，在計算表儲存空間的時候要切記
5、date
date型別是乙個7位元組的定長資料型別，沒啥好說的，乙個例子：效能a>b>c
a、where date_colum>=to_date(』01-jan-2007』,』dd-mon-yyyy』)
and date_colum< div>
b、where trunc(date_colum,』y』)=to_date(』01-jan-2007』,』dd-mon-yyyy』)
c、where to_char(date_colum,』yyyy』)=』2007』
6、 timestamp/timestamp with time zone/timestamp with local time zone
和date類似，只不過它另外支援小數秒和時區。語法timestamp(n)，n指定秒的小數字數，取值範圍0～9。可選。
7、lob
a、 乙個lob欄位包括lobindex和lobsegment
b、 lob預設可以存放在表中（表字段），條件是：
1.它的大小小於4kb
2.並且在定義的時候沒有使用(disable storage inrow)字句（預設是enable）
當lob大於4kb的時候它會被存放到lobsegment中
c、當lob存放在表中的時候，它可以被快取，對於它的操作效率遠遠高於儲存在lobsegment中的lob（不用lobindex）
d、 儲存在lobsegment中的lob預設不在緩衝區快取，對於lob的讀寫都是物理io，代價非常高，所以對於大於4kb的lob欄位千萬不要頻繁更新，效率非常低
e、 儲存在lobsegment中的lob可以在定義的時候指定使用cache（預設是nocache），這對於中等大小的lob（比如幾k～幾十k）很有用處，同時，它還可以減少物理io。
如何設計資料庫
表與表之間的關係 例如下圖 假設使用者下單需要哪些表？每張表設計什麼字段，要用什麼型別 例如 建立個user表 create table t user id int 11 not null auto increment comment 使用者表id username varchar 50 not n...
如何設計資料庫 1 ？
為什麼需要設計資料庫 這裡我們思考兩個問題 修建茅屋需要設計嗎？修建大廈需要設計嗎？結論是 當資料庫比較複雜 如資料量大，表較多，業務關係複雜 時，我們需要先設計資料庫 因為，良好的資料庫設計能夠 q節省資料的儲存空間 q能夠保證資料的完整性 q方便進行資料庫應用系統的開發 糟糕的資料庫設計 q資料...
如何設計資料庫 2
資料規範化 僅有好的rdbms並不足以避免資料冗餘，必須在資料庫的設計中建立好的表結構。表設計後，很可能結構不合理，出現資料重複儲存，簡稱資料的冗餘，這對資料的增刪改查帶來很多後患，所以我們需要審核是否合理，就像施工圖設計後，還需要其他機構進行審核圖紙是否設計合理一樣。如何審核呢？需要一些有關資料庫...