其實就乙個點，有總比沒有好
當你想查詢統計的時候，發現當時沒有記錄，那就是不可估量的損失，歷史失去了就不再重現。
現在硬碟這麼大，別吝嗇一點空間。
1、表必須有的字段
id自增 主鍵
沒有主鍵的表，效能難以想象
建立時間
建立者建立ip
能追溯記錄產生
修改時間
修改者修改ip
修改日誌
能追溯記錄修改
是否刪除
代替物理刪除
2、別輕易做物理刪除
物理刪除是下策，打個標記就好了；
人總會犯錯，知錯能改善莫大焉。知錯想改，改不了，那就是杯具。
還是那句話，有總比沒有好。有可以不要，沒有想要都不得。囧
個人經驗僅供參考。
資料庫設計經驗談 下
資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...
資料庫設計經驗談 下
引用 http blog.csdn.net softj services trackbacks 497813.aspx 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從...
資料庫設計經驗談 4
第 4 部分 保證資料的完整性 如果你按照商務規則來處理需求，那麼你應當檢查商務層次 使用者介面 如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護資料完整性的需要，那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用使用者...