直接在数据库系统中实现功能/代码

时间:2008-10-08 23:35:06

标签: database

今天的RDBMS软件包提供了超出标准数据存储和检索的大量功能。例如,SQL Server可以发送电子邮件,公开Web服务方法,并在其他功能中执行CLR代码。但是,我一直试图尽可能地限制数据库服务器对数据存储和检索的处理量,原因如下:

  • 数据库服务器比Web服务器更难扩展
  • 在我参与的很多项目中,数据库服务器比网络服务器繁忙,因此备用容量更少
  • 它可能会将您的数据库服务器暴露给安全攻击(例如Web服务)

我的问题是,您如何决定应该在数据库服务器上直接实现多少功能或代码而不是架构中的其他服务器?您对开始新项目的人有什么建议?

2 个答案:

答案 0 :(得分:4)

我知道Microsoft SQL Server和Oracle真正推动使用存储过程来处理所有事情,这有助于封装关系体系结构并为软件开发人员创建更具程序性的界面,而软件开发人员通常不那么容易编写SQL查询。

但是,一半的应用程序逻辑是用PL / SQL(或T-SQL或其他)编写的,另一半是用您的应用程序语言,Java或PHP或C#等编写的.DBA通常负责编写程序,开发人员负责其他一切。没有人可以看到并访问完整的应用程序逻辑。这往往会减慢项目的开发,测试和未来修订。

此外,软件开发工具对于存储过程来说往往很差。用于调试,源代码控制和测试的工具和最佳实践似乎都比应用程序语言的技术发展落后了大约10 - 15年。

因此,如果可能的话,我倾向于远离存储过程和触发器。除非在某些情况下,放置良好的存储过程可以使复杂的SQL操作完全在服务器中发生,而不是来回移动数据。这可以非常有效地消除性能瓶颈。

也可能在另一个方向走得太远。喜欢应用程序管理数据与元数据,并采用实体 - 属性 - 值或多态关联等设计的人会遇到麻烦。让数据库管理它。使用参照完整性约束(外键)。使用交易。

答案 1 :(得分:0)

供应商有一套最佳实践。但是,你对此表示担忧。

多年前,我支持主要软件产品。主要

他们说“数据库是关系存储。没有更多。”每个用户会议都会询问存储过程,触发器以及所有关键信息。

他们的建筑师很坚定。一旦你摆脱了普通的SQL,你就会得到支持和维护的噩梦。他们进行了从数据库到产品的对象关系映射,其他一切都在他们的产品中。

这很好。多个应用程序服务器可以轻松共享单个数据库服