最近除了在規劃內部使用的小系統外，在家的空閒時間大都在拜讀獨孤木老大的軟體超人X光眼，增加點見識。
敝公司四年前在導入台灣最大ERP軟體公司的電子公文時，就如同此書Story 16所提，不斷地delay又一直change request。到後來都和對方工程師混熟，他們也不好意思拒絕request。此公文系統的規劃應該是在上個世紀末，約1997~1998吧（我猜的）。他們的問題與採用asp撰寫沒有關係，約爾都能用來寫出FogBugz這種高水準的軟體。我個人認為此軟體失敗在兩個地方，第一個是採用過時的RDS呼叫，而且都直接用ActiveX與DB連絡（雖然透過COM，但其實沒差別），另一個是沒有使用DB的Key來檢核，所以程式若沒有檢查到的地方，就很容易出錯。
Primary Key主要的功能就是確保資料的唯一性，另外也會自動產生一份index。Foreign Key除了能確保資料外部條件約束外，也能自我約束。例如說，在什麼都不奇怪的網站，分類樹的建立。第一個欄位是id，PK；第二個欄位是parent，FK關連到id，allow null。這樣就形成一個自我描述的tree，在parent為null的都是第一層，parent指向第一層id的都是第二層，照這樣recursion就把整個分類樹建出來。
善用PK與FK，就可以避免在程式邏輯做出過多的判斷，由DB所丟出的錯誤訊息就可以知道發生什麼事。
雖然是20世紀的產物，但是畢竟是在21世紀做的專案，怎麼會有這麼離譜的事呢？我自己學Databae是在當兵是K一本"SQL的奧秘"而已，玩MySQL和Oracle也沒做出這種恐怖的設計。後來又看到另一公司MIS做的產品，連primary key都沒有，這又是另一個故事了...
參考資料：強制資料完整性 （微軟的線上叢書還真不賴）
敝公司四年前在導入台灣最大ERP軟體公司的電子公文時，就如同此書Story 16所提，不斷地delay又一直change request。到後來都和對方工程師混熟，他們也不好意思拒絕request。此公文系統的規劃應該是在上個世紀末，約1997~1998吧（我猜的）。他們的問題與採用asp撰寫沒有關係，約爾都能用來寫出FogBugz這種高水準的軟體。我個人認為此軟體失敗在兩個地方，第一個是採用過時的RDS呼叫，而且都直接用ActiveX與DB連絡（雖然透過COM，但其實沒差別），另一個是沒有使用DB的Key來檢核，所以程式若沒有檢查到的地方，就很容易出錯。
Primary Key主要的功能就是確保資料的唯一性，另外也會自動產生一份index。Foreign Key除了能確保資料外部條件約束外，也能自我約束。例如說，在什麼都不奇怪的網站，分類樹的建立。第一個欄位是id，PK；第二個欄位是parent，FK關連到id，allow null。這樣就形成一個自我描述的tree，在parent為null的都是第一層，parent指向第一層id的都是第二層，照這樣recursion就把整個分類樹建出來。
善用PK與FK，就可以避免在程式邏輯做出過多的判斷，由DB所丟出的錯誤訊息就可以知道發生什麼事。
雖然是20世紀的產物，但是畢竟是在21世紀做的專案，怎麼會有這麼離譜的事呢？我自己學Databae是在當兵是K一本"SQL的奧秘"而已，玩MySQL和Oracle也沒做出這種恐怖的設計。後來又看到另一公司MIS做的產品，連primary key都沒有，這又是另一個故事了...
參考資料：強制資料完整性 （微軟的線上叢書還真不賴）
留言
剛好我最近也看到一個沒有PK的資料庫，您說這又是一段故事，那您認為當時看到的那個資料庫為什麼沒有PK？
舉例來說：員工打卡時間的資料表在國內不少打工鐘公司做出來的都沒有PK，因為他們認為用time+employee id就可以找出來，結果企業MIS要重用該資料表時卻遇到資料重覆的問題。