推薦：SQL Server 2005分析服務 統一整合視圖
統一的空間模型 分析服務提供了一個商務語義模型，被稱為統一的空間模型 (UDM)。該模型定義了商務實體、商務邏輯、計算和度量。UDM 是一個中心位置，充當所有報告、電子表格、OLAP瀏覽器、KIP

無論是在小得可憐的免費數據庫空間或是大型電子商務網站，合理的設計表結構、充分利用空間是十分必要的。這就要求我們對數據庫系統的常用數據類型有充分的認識。下面我就將我的一點心得寫出來跟大家分享。

一、數字類型

數字類型按照我的分類方法分為三類：整數類、小數類和數字類。

我所謂的“數字類”，就是指 DECIMAL 和 NUMERIC，它們是同一種類型。它嚴格的說不是一種數字類型，因為他們實際上是將數字以字符串形式保存的;他的值的每一位 (包括小數點) 占一個字節的存儲空間，因此這種類型耗費空間比較大。但是它的一個突出的優點是小數的位數固定，在運算中不會“失真”，所以比較適合用于“價格”、“金額”這樣對精度要求不高但準確度要求非常高的字段。

小數類，即浮點數類型，根據精度的不同，有 FLOAT 和 DOUBLE 兩種。它們的優勢是精確度，FLOAT 可以表示絕對值非常小、小到約 1.17E-38 (0.000...0117，小數點后面有 37 個零) 的小數，而 DOUBLE 更是可以表示絕對值小到約 2.22E-308 (0.000...0222，小數點后面有 307 個零) 的小數。FLOAT 類型和 DOUBLE 類型占用存儲空間分別是 4 字節和 8 字節。如果需要用到小數的字段，精度要求不高的，當然用 FLOAT 了。可是說句實在話，我們“民用”的數據，哪有要求精度那么高的呢?這兩種類型至今我沒有用過――我還沒有遇到適合于使用它們的事例。

用的最多的，最值得精打細算的，是整數類型。從只占一個字節存儲空間的 TINYINT 到占 8 個字節的 BIGINT，挑選一個“夠用”并且占用存儲空間最小的類型是設計數據庫時應該考慮的。TINYINT、SMALLINT、MEDIUMINT、INT 和 BIGINT 占用存儲空間分別為 1 字節、2 字節、3 字節、4 字節和 8 字節，就無符號的整數而言，這些類型能表示的最大整數分別為 255、65535、16777215、4294967295 和18446744073709551615。如果用來保存用戶的年齡 (舉例來說，數據庫中保存年齡是不可取的)，用 TINYINT 就夠了;九城的《縱橫》里，各項技能值，用 SMALLINT 也夠了;如果要用作一個肯定不會超過 16000000 行的表的 AUTO_INCREMENT 的 IDENTIFY 字段，當然用 MEDIUMINT 不用 INT，試想，每行節約一個字節，16000000 行可以節約 10 兆多呢。

二、日期時間類型

日期和時間類型比較簡單，無非是 DATE、TIME、DATETIME、TIMESTAMP 和 YEAR 等幾個類型。只對日期敏感，而對時間沒有要求的字段，就用 DATE 而不用 DATETIME 是不用說的了;單獨使用時間的情況也時有發生――使用 TIME;但最多用到的還是用 DATETIME。在日期時間類型上沒有什么文章可做，這里就不再詳述。

三、字符 (串) 類型

不要以為字符類型就是 CHAR，CHAR 和 VARCHAR 的區別在于 CHAR 是固定長度，只要你定義一個字段是 CHAR(10)，那么不論你存儲的數據是否達到了 10 個字節，它都要占去 10 個字節的空間;而 VARCHAR 則是可變長度的，如果一個字段可能的值是不固定長度的，我們只知道它不可能超過 10 個字符，把它定義為 VARCHAR(10) 是最合算的，VARCHAR 類型的占用空間是它的值的實際長度 1。為什么要 1 呢?這一個字節用于保存實際使用了多大的長度。從這個 1 中也應該看到，如果一個字段，它的可能值最長是 10 個字符，而多數情況下也就是用到了 10 個字符時，用 VARCHAR 就不合算了：因為在多數情況下，實際占用空間是 11 個字節，比用 CHAR(10) 還多占用一個字節。

舉個例子，就是一個存儲股票名稱和代碼的表，股票名稱絕大部分是四個字的，即 8 個字節;股票代碼，上海的是六位數字，深圳的是四位數字。這些都是固定長度的，股票名稱當然要用 CHAR(8);股票代碼雖然是不固定長度，但如果使用 VARCHAR(6)，一個深圳的股票代碼實際占用空間是 5 個字節，而一個上海的股票代碼要占用 7 個字節!考慮到上海的股票數目比深圳的多，那么用 VARCHAR(6) 就不如 CHAR(6) 合算了。

雖然一個 CHAR 或 VARCHAR 的最大長度可以到 255，我認為大于 20 的 CHAR 是幾乎用不到的――很少有大于 20 個字節長度的固定長度的東東吧?不是固定長度的就用 VARCHAR。大于 100 的 VARCHAR 也是幾乎用不到的――比這更大的用 TEXT 就好了。TINYTEXT，最大長度為 255，占用空間也是實際長度 1;TEXT，最大長度 65535，占用空間是實際長度 2;MEDIUMTEXT，最大長度 16777215，占用空間是實際長度 3;LONGTEXT，最大長度 4294967295，占用空間是實際長度 4。為什么 1、 2、 3、 4?你要是還不知道就該打 PP 了。這些可以用在論壇啊、新聞啊，什么的，用來保存文章的正文。根據實際情況的不同，選擇從小到大的不同類型。

四、枚舉和集合類型

枚舉 (ENUM) 類型，最多可以定義 65535 種不同的字符串從中做出選擇，只能并且必須選擇其中一種，占用存儲空間是一個或兩個字節，由枚舉值的數目決定;集合 (SET) 類型，最多可以有 64 個成員，可以選擇其中的零個到不限定的多個，占用存儲空間是一個到八個字節，由集合可能的成員數目決定。

舉個例子來說，在 SQLServer 中，你可以節約到用一個 BIT 類型來表示性別 (男/女)，但 MySQL 沒有 BIT，用 TINTINT 嗎?不，可以用 ENUM('帥哥','美眉')，只有兩種選擇，所以只需一個字節――跟 TINYINT 一樣大，但卻可以直接用字符串 '帥哥' 和 '美眉' 來存取。真是太方便啦!

好了，MySQL 的數據類型介紹得差不多，我的建庫策略也隨著介紹數據類型介紹給大家一些。但這只是其中一部分，篇幅有限，不能再細說;其他的，就靠各人在對數據類型理解的基礎上，多多實踐、多多討論。

分享：SQL“多字段模糊匹配關鍵字查詢”
我們開發數據庫應用時，常常需要用到模糊查詢。如果同一個條件需要匹配很多字段怎么辦呢？通常，程序員會每個字段都在SQL中“field like'%cond%'”一次。這樣，SQL語句會長得驚人，碰