我要看ㄧ下实际的例子才能够知道 这些更动的逻辑应该放在哪里比较适合 例如 如果是ㄧ些正规化的的表格 当更动ㄧ笔资料时候 会因为参考完整性 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