我要看ㄧ下實際的例子才能夠知道
這些更動的邏輯應該放在哪裡比較適合
例如 如果是ㄧ些正規化的的表格
當更動ㄧ筆資料時候
會因為參考完整性
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