您的数据库应用程序应该在存储过程中有多少？

Question

我正在为数据库应用程序编写第二个接口,以解决原始接口的一些缺点.不幸的是,如果我创建新记录,则不会生成预期的审计跟踪记录.如果数据库设计已经将这些细节用于表触发器,那么肯定会很好,或者为诸如将新记录插入这些表之类的操作提供存储过程API.

应用程序应该以这种方式设计吗？存储过程中应该有多少数据库应用程序？

Answer 1

我们的团队有一条规则 - 任何进出数据库的数据都必须通过存储过程.我们甚至已经对我们的数据访问组件构建限制以强制执行此操作.

至于其他事项,如簿记,审计跟踪等,我们也将它们放在存储过程中.触发器很方便,但我们发现,为了审计日志的目的,涉及更新的人员,内容和时间,并不是我们想要的所有数据都可用于触发器.我们曾经使用触发器的唯一一次是保持表中每条记录的完整更改历史记录,但即便如此,事后看来,它也会导致维护问题,并且对我们来说更好.

Answer 2

这完全取决于您的环境.这个问题的答案实际上不是编码问题,甚至是分析问题,而是商业决策.

如果您的数据库只支持一个应用程序,并且与其紧密集成,那么出于灵活性的原因,最好将逻辑放在应用程序中.在这些情况下,将数据库简单地作为使用通用功能的普通数据存储库处理会使您失去灵活性并获得灵活性 - 包括供应商,实现,部署以及其他许多因素 - 以及'数据库用于数据'群众所做的许多纯粹论证都是示范性的真正.

在另一方面,如果你正在处理一个公司的数据库,这通常可以通过具有多路径访问它也可以识别,那么它是非常可取的,只要你能拧紧安全.至少应启用所有适当的约束,并且如果可能,仅应通过视图和过程访问数据.在这些情况下应该忽略呜呜的程序员......

1. 使用公司数据库,资产是有价值的,无效数据或操作可能会对业务造成威胁.您主要关注的是保护业务,而不是为您的程序员提供便利.
2. 根据定义,此类数据库可由多个应用程序访问.您需要使用存储过程提供的抽象,以便在升级应用程序A并且您没有资源升级应用程序B时可以更改数据库.
3. 类似地,在SP中而不是在应用程序代码中封装业务逻辑允许比在应用程序代码中嵌入这样的逻辑更容易和可靠地在整个业务中实现对这种逻辑的改变.例如,如果计算必须在一个SP中更改而不是多个应用程序,那么如果税收计算更改,则工作量更少,更稳健.这里的经验法则是业务规则应该在最接近数据的位置实现 - 因此,如果您有专家应用程序,那么该应用程序的逻辑可以在该应用程序中实现,但逻辑更广泛适用应该在SP中实施业务.

在您的情况下,您现在有多个应用程序访问同一个数据库,因此您应该将逻辑和审计功能从应用程序级别移动到数据库中.我自己通常会将审计功能放入数据库本身,因为如果我曾经被要求调查一些欺诈问题(并且它已经发生了不止一次)我只是觉得我可以站起来并确定我的发现更多信心比在应用层中还要少 - 这种警告的机会就少了.

关于使用或不使用SP的宗教战争的编码人员通常只在一个环境或另一个环境中工作,因此他们将他们有限的经验推断为铸铁位置 - 这在他们的背景下确实是完全可辩护和正确的.来但是错过了大局.与往常一样,您应该让您决定业务/客户/用户的需求,而不是您喜欢哪种编码方法.