※ 引述《seagal (會長繞跑了)》之銘言： : 在OO的思維裡 : 每個物件是不需要PK的 理論與現實是有差別的 OID在RDBMS是類似那種額外附加的代理鍵 有時候代理鍵在應付資料庫的一致性是很弱的 : 你也可以說她們本身就有PK : 因為每個物件都會自己產生獨一無二的ID : 這也是現在的OODB實做的方式 : 而在上面我舉的例子裡面 : 我總是要透過News模組的PK (NewsID)來讀取每個tuple : 最後一個問題 : 在傳統的結構化分析與設計 : 將每個階段都切的十分清楚 : 而如果用OOA/OOD的方式來開發的話 : 並不會產出ER Model的文件(上面提過這是結構化分析 設計的產物) : 有些DBA也沒有學過UML(至少我們team的DBA沒有學過) : 那分析階段產出的UML該由誰負責轉成ER Model呢 嚴格來說DBA是管理已經上線的DB DB的設計是DB設計師的事情 除非這兩個角色重疊... : 萬能的SA/SD嘛 : 或是像come網友講的 : 在分析階段就產出ER Model : 後面的設計都繞著ER Model來做? : 這也就是說 : 把OOA/OOD以資料導向的方式來開發? 難道OOA, OOD就不需要用到資料庫嗎? 應該說資料庫的部份是用資料導向在開發 其他部分不是 : 我的領域並不在OODB上面 : 我只是最近剛好有需要 : 將生物資訊的大量資料作處理 : 有必要的話可能還是得硬著頭皮弄出適合的一套檔案(or DBMS)系統 : 所以如果有任何高手能指正的話 : 也歡迎針對我說錯的地方指正 : : analysis階段的class diagram只是一個雛形而已 : : 到了design階段的class diagram還必須根據data base schema重新設計一次 : : 那你覺得這時候class diagram的設計是要遷就DB : : 還是要回頭改DB設計? : : spiral model的開發模型是可以這樣搞 : : 不過改到DB通常表示需求分析有問題 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.223.42.62