没有存储过程或触发器工作

在过去的18个月里,我们一直在研究复杂的数据库和客户端界面.我们定期为此应用程序添加新功能,现在我们所有办公室(包括站点和海外)每天都有数十名用户使用它.这只是告诉你它是一个真正的应用程序与REAL数据库.

到目前为止,我们仍然没有编写任何存储过程,除了临时解决客户端版本和更新的数据库模型之间的小问题(旧的客户端版本将无法正确更新新创建的字段,直到每个人都安装最新的版).

同样,我们仍然不需要任何触发器.实际上,唯一的SP和触发器是系统的,或者是为复制目的而添加的.

我有一种奇怪的感觉,当开发人员认为数据库优化必须反对数据库规范化时,SP和触发器主要用于补偿数据库设计默认值和/或试图绕过数据库设计规则.

问题是这些工具很耗时(用于开发或维护).然后,每个开发人员都应该非常小心地使用它们,请记住它们是在数据库中维护的最"昂贵"的项目.

我们是否可以认为在数据库中没有或几乎没有存储过程/触发器是它的标准化水平和/或代码维护成本的良好指示？

编辑:

有些人为使用触发器和SP提供了公平的参数.但我一直认为,大多数时候这些工具是以不正当或过度的方式使用的.设置了多少个触发器来在表字段之间进行一些奇特的更新,或者重新计算总计或其他聚合数据？有多少SP用于构建用于报告问题的临时表？在开发人员使用这些工具的许多情况中,这些是2,我认为这通常说明了数据库设计/规范化缺陷.

其他一些人承认应严格控制SP和触发器的使用.我发现它也是必要的.

我必须承认,我试图找到一些崇尚参数,所有我们的其他数据库的工作,这些SQL怪才瞧不起我们,告诉自己的朋友:"你知道吗？他们甚至不使用SP和触发器!哈哈!"

我们是否可以认为在数据库中没有或几乎没有存储过程/触发器是它的标准化水平和/或代码维护成本的良好指示？

你不能.

规范化和存储过程彼此完全分离.

我对SP的看法是数据库和使用它的人之间的抽象层.

强制人们使用SP而不是直接CRUD操作将更容易更改表的设计而不会破坏它们.

存储过程和触发器是工具 - 在数据库管理系统中使用的非常具体的工具.

触发器具有多种用途,从大大简化历史表的维护(其中每一行代表主表的过去时间段)到将ETL的请求排队到数据仓库(取决于特定的RDBMS)

无论是从应用程序还是从SQL命令行工具调用存储过程,它们都有其自己的位置.

包含存储过程或触发器实际上与规范化或"数据库设计默认值"无关.它们在应用程序中的使用通常直接与应用程序的其他要求相关,包括可伸缩性,可靠性,复制或其他要求,这些要求可以通过使用这些工具得到最有效的满足.

如果你不需要他们,不要使用他们.但是,不要假设触发器或存储过程的存在表明设计不佳.

除了在代码中遇到大量的内嵌SQL之外,没有什么比这更容易了.至少使用Stored Proc,您可以对其进行语法检查,甚至执行它以查看问题所在.更不用说它会比保存执行计划时在DB上发出查询更快.我一直认为数据库代码属于数据库,但这只是我的看法.

触发器有它们的用途.它们并不总是最好的,但肯定是有原因的.

至于存储过程,我们不要忘记安全问题.允许应用程序运行内联SQL意味着您的用户帐户需要对所有表进行直接读取,插入,更新和删除访问.如果存在违规行为,则会泄露您的数据库.

触发器有它们的位置.特别是在有很多数据库开发人员可能会或可能不知道(例如)SOX要求的环境中,我们会保留预算信息变更的历史记录.