是否有行业标准或规则......?

时间:2016-01-21 14:42:15

标签: sql-server database web-standards

我有一个同事在我们开发的网站上为每个CONTROL创建一个新数据库(这是对的,我说CONTROL)。我的工作场所从供应商和我的同事那里购买了一个门户网站,我开发了自定义控件以在门户网站内工作。但是,我的同事和我一直在争吵。

我曾经工作过的地方没有为门户网站上创建的每个控件创建一个新数据库。

他为在此门户网站上创建的每个控件创建一个新数据库(而不是新表)。他的理由是他想要隔离一个问题,如果一个问题发生,如果数据库被泄露,那么它将被隔离到那个控制数据库。

这听起来不错,但我相信它会导致其他问题,例如:   - 他复制其他数据库中的表和数据   - 重复数据的可管理性   - 如果任何控件提取数据,它并不保证它是最新的,如果它是一个财务控制,可能会导致其他领域的计算问题   - 维护更新重复数据的工具   - 多个实例将消耗更多的整体内存和存储空间   - 多个实例将创建更多监控   - 多个实例将产生更多管理问题(维护新用户帐户)   - 盒子上的多个实例将更难调整   - 使用单个数据库可以更轻松地维护DATA INTEGRITY

这个人和我一样拥有相同的职位和职责,但我没有权力告诉他改变他的方式。

我的问题是:是否有行业标准或规则规定不为网站上的每个控件创建新数据库?

令人沮丧的情况......

1 个答案:

答案 0 :(得分:1)

一般情况下,请记住以下几点:

  • 服务器是连接单元(应用程序连接到服务器)。
  • 数据库是单元恢复(因此备份)并驻留在服务器上。
  • 架构是安全的单位,驻留在数据库中。
  • 表保存数据并驻留在模式中。

我不完全明白什么是“控制”。但是,如果您需要不同的恢复机制,那么为一个数据库创建数据库是合适的。对于不同的应用将是这种情况。可能还有其他注意事项,例如数据可见性,存储过程等。

否则,可能应该通过以下方式之一支持它:

  • 单个表格中的所有数据。
  • 同一架构中的多个表。
  • 多个模式,每个控件一个。

您的同事对安全性的担忧令人钦佩,但不同的数据库并不是正确的解决方案。如果您有DBA,那么您应该与DBA讨论直接加密磁盘上的数据 - 因此即使没有密钥,备份也是安全的。此外,安全性违规在服务器级别与数据库级别一样可能发生,并且将数据存储在不同的数据库中也无济于事。事实上,除非你有一个非常智能的恢复/备份策略,否则它可能会让你处于危险之中。