然後前面加上編號如: 111學歷, 112職業, 101性別 來區分.
而再過一陣子發現, 這些屬性資料表也太多了, 而且結構都有點像, 基本上有幾個特徵:
1. 不屬於業務上的特性, 所以不常因為某種業態而換, 只會選擇要不要用這些項目.
2. 基本上一定有一個 ID 或 SN , 然後有一串文字說明, 可能再有最多兩個變數.
3. 異動率很低, 讀取率很高, 適合建立 index .
既然結構, 用途都差不多, 就直接開個資料表, 把相關屬性都放在裏面, 而原本的資料表編號就換成屬性編號, 看起來就像:
| 屬性ID | ID | 說明 | 變數1 | 變數2 |
|---|---|---|---|---|
| 0000 | 1001 | 性別 | ||
| 0000 | 1011 | 學歷 | ||
| 0000 | 1012 | 職業 | ||
| 0000 | 1021 | 年齡區間 | ||
| 0000 | 2001 | 公司名稱 | xxx股份有限公司 | |
| 0000 | 2002 | 公司代表號 | (039)123-xxx | |
| 1001 | M | 男 | ||
| 1001 | F | 女 | ||
| 1001 | O | 其他 | ||
| 1001 | O | 其他 | ||
| 1011 | 0 | 未就學 | ||
| 1011 | 1 | 小學(國校) | ||
| 1011 | 2 | 初中 | ||
| 1021 | 0 | 未填 | ||
| 1021 | 18 | 18歲以下 | 0 | 18 |
| 1021 | 30 | 19~30歲 | 19 | 30 |
而可以把原本的資料表取消, 改用同名的"查詢(view)", 需要顯示某些屬性時, 就可以改用查詢, 或在條件上加上屬性 ID 來篩選.
因為屬性 ID 與 ID 兩個合併起來, 這屬性有唯一性, 就可以拿來當 Primary Key , 也可以建立 index .
算是最近在改版上的新發現吧....
