我要看ㄧ下實際的例子才能夠知道 這些更動的邏輯應該放在哪裡比較適合 例如 如果是ㄧ些正規化的的表格 當更動ㄧ筆資料時候 會因為參考完整性 cascade的去修改每一筆參考記錄的資料 這樣的情形就ㄧ定得放在預存程序裡面 而FK的屬性也要設定好 讓資料可以cascade的修改或刪除 若更新資料或屬性 牽涉到物件之間的互動 而不光僅僅只是關聯式資料庫的參考完整性的問題的時候 就適合在資料邏輯層處理掉 讓物件之間先作完她們的工作 最後再透過資料存取層存到資料庫裡 所以我簡略的做個結尾 假設你的系統是用物件導向的方式設計 資料庫是用關聯式資料庫 中間的橋樑是使用OR-mapping 在做系統分析的階段 會將類別圖生出來 這時候你可以使用UML的其他圖來捕捉你系統的事件與行為 大致上在這個階段 物件之間的互動 所造成的狀態的變化 ㄧ般都是在邏輯層處理掉的 而資料庫的預存程序做的事情就很簡單了 他只要負責 丟出資料 產生出你所需要的物件(中間的過程用OR mapping轉) 更新資料 更新物件裡面的屬性(實際上的動作就會更新到資料庫的表格) 你可以簡單的視為 資料邏輯層是負責物件之間的互動 資料庫的每ㄧ隻預存程序 負責維護每ㄧ個物件內的屬性 當然這還是有例外 在設計階段也有可能因為硬體效能考量 將某些動作在不同的layer裡面移動 要動手做才能體會該怎樣分工比較適合 設計只有比較好 或是比較差的設計 也沒有絕對正確的 ※ 引述《foxzgerald (O⊥M)》之銘言： : ※ 引述《seagal (會長繞跑了)》之銘言： : : 我以三層式的架構來解釋的話 : : 資料存取層對應資料庫裡面的sp(這兩個是不一樣的東西喔) : : 但我不知道你使用PHP時會不會用到三層式架構 : : J2EE & .NET都可以很輕易的將商業邏輯放在中間的邏輯層 : : 最底層的資料存取層只做一些新增 修改 刪除 以及選取資料的動作 : : 所以sp裡面只需要放很簡單的提取資料 修改資料 新增資料 這些動作就好了 : 目前手上專案的資料庫結構有點小複雜， : 變更一筆資料可能牽動另外兩三張 table。 : 如果以方便維護為考量，應該把這些處理邏輯放在資料存取層； : 如果以效率考量，應該把邏輯放在 SP 裡頭(避免資料在 php/mysql 中穿梭) : ...不知道這樣的概念正不正確? : 老實說，我對資料存取層和 SP 的設計上的分野感到有些疑惑。 : 這兩個似乎是融在一起的灰色漸層 ╮(╯_╰)╭ --

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