資料庫設計三闆斧

簡單粗暴點,但效果比較明顯.扔出來引玉. 1、根據業務需求，按照範式設計正常化的資料庫結構 2、把報表一張張的過，審驗現在的表結構是否可以滿足統計報表容易的出。不容易出的，自行設計額外的表、視圖、自定義函數 3、把功能中的查詢Grid清單、查詢條件拿出來一張張的過，審驗現在的表結構是否可以滿足查詢容易的出。不容易出的，自行設計額外的表、視圖、自定義函數 很多人不知道在設計期如何加索引,在什麼字段上加索引,是加聚集索引還是非聚集索引.我個人的經驗是: A、主鍵一般是聚集索引，但聚集索引是要求最好是有序的，因為聚集索引要決定實體記錄存放，是以咱們的GUID主鍵字段最好變成有序GUID。SQLSERVER2005專門有方法可以使GUID有序。 B、看資料庫E-R圖，表之間的外鍵關系（可能你并沒有建立真正資料庫外鍵，但事實上存在外鍵關系），把最頻繁使用的那幾張核心業務資料表之間的外鍵關系建立好非聚集索引。這是JOIN關聯經常用的。 C、把查詢和報表都過一遍,把查詢參數和報表參數審視一下,這是經常要做的查詢條件。根據主鍵和查詢條件，綜合得出非聚集索引的選擇。 經過這三招選擇的索引，它不會是在客戶生産環境下最優的索引，但它也是中等偏上的水準，這樣就可以讓沒有索引優化經驗的人也可以有方法的設計出有一定水準的資料庫表結構和索引。 經過三闆斧，這個資料庫設計就比較滿足查詢、增删改、統計報表的需求了。 如果還怕資料表設計有閃失，那就額外送你一斧，那就是： 4、對于單據操作的，是否要留下過程字段資訊變更記錄。這樣你在回溯資料、統計某個曆史時間階段的資料就非常容易。 如果你還不放心，那麼再送你一斧子，那就是： 5、從業務功能的操作頻繁程度，操作使用者量，資料增長速度來估算一張表一年、3年、5年的資料增長量，通過估算的資料規模來再一次設計備援表、曆史資料表。 其他什麼有序GUID索引、聚集索引選擇、預設值與不可為空限制、關鍵核心表使用外鍵保證資料完整性，都是後話。 有時候，解決大部分問題，隻需要簡單幾下。不信，你試試看。人說書生百無一用，很多時候就是叫真半天研究半天，得出來的結論和老百姓的常識是一樣一樣的。