我需要设计一个Windows应用程序,该应用程序代表SQL Server中的多个“客户”。每个客户都有相同的数据模型,但是是独立的。
使用多个数据库与使用单个数据库的利弊是什么?
哪一种是完成这项工作的最佳方法。如果要使用单个数据库,将执行哪些步骤。
编辑:
一件事是数据库将托管在云(机架空间)帐户中。
不要将来自多个客户的数据存储在同一个数据库中-我知道一些公司不得不花费大量时间/精力/金钱来修复此错误。我什至知道,即使数据库是分开的,客户也愿意共享数据库计算机-从正面来看,这些客户通常愿意为额外的硬件付费。
仅凭安全性问题就应该阻止您执行此操作。因此,您将失去大量客户。
如果您有一些客户不愿升级他们的软件,则共享一个数据库可能会非常困难。单独的数据库允许客户继续使用旧的数据库结构,直到他们准备升级为止。
您人为地限制了可以为您的解决方案提供可伸缩性的自然数据分区。多个小型客户仍然可以共享数据库服务器,他们只能看到自己的数据库/目录,或者可以在单独的数据库服务器/实例上运行。
您正在使数据库设计复杂化,因为您将不得不区分本来会自然分离的客户数据,即必须在每个where子句中提供CustomerID。
通过在所有表中增加行,使数据库变慢。由于CustomerID现在是每个索引的一部分,并且每个索引节点中可以存储的记录更少,因此您将更快地耗尽数据库内存。由于失去了参考位置的固有优势,您的数据库也变慢了。
1个客户的数据回滚可能非常困难,甚至可能随着数据库的增长而根本无法回滚-与从备份中进行简单而标准的还原相比,您将需要自定义过程来执行此操作,此过程要慢得多且占用大量资源。
大型数据库可能很难及时进行备份/还原,可能需要在硬件上花费额外的资金才能使其足够快。
使用数据库的应用程序将更难以维护和测试。
任何错误都可能更具破坏性,因为您可能会因为一个错误而使所有客户陷入困境。
通过将数据库强制到单个位置,可以防止低延迟的性能增强。例如,海外客户将一直使用慢速,高延迟的网络。
您将被称为愚蠢的DBA,失业的DBA或两者兼而有之。
但是,共享数据库设计有一些优点。
通用表架构,代码表,存储的proc等仅需维护并存储在1个位置。
在某些情况下,许可成本可能会降低。
尽管几乎可以肯定的是,使用组合方法总体上会使总维护工作变得更糟,但维护起来更为容易。
如果您的所有客户端/全部客户端都很小,则不合并服务器就可以降低资源利用率(例如,相对较高的成本)。您可以通过将客户与他们的权限和明确的理解相结合来减轻高昂的成本,但是对于大型客户仍然使用单独的数据库。在这种情况下,您绝对需要明确并事先与客户取得联系。
除了服务器成本分摊之外,这仍然是一个非常糟糕的主意-但成本也可能是非常重要的方面。这实际上是采用这种方法的唯一理由-尽一切可能避免这种情况。也许您最好对产品进行一些更改,或者只是不能以低廉的价格支持小客户。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句