我有一个客户端正在使用的桌面应用程序，每个客户端都可以访问自己的本地网络数据库。 我的经理已经决定最好合并这些数据库并且只有一个。然后，所有客户端将通过位于云上的Web服务访问该数据库。在我们继续做出这个决定之前，我想权衡利弊。 我们拥有的一个选项是在每个表中都有一个ClientID，这将导致每个表都有一个复合键。
我听说过另一个选择是使用模式。请告知模式方式如何工作，这是与每个表中都有复合键相比的最佳方法。 谢谢。
答案 0 :(得分：2)
这是一项非常困难且耗时的任务。您需要进行广泛的回归测试，因为破坏的风险很大。
让我告诉你一个客户端的故事，该客户端在一个单独的服务器上有一个单独的数据库，该服务器与另一个包含许多客户端的数据库合并。花了几个月的时间才进行所有更改以转换数据。一切看起来都不错，它被推向了刺激。不幸的是，开发人员错过了一个需要引用客户端ID的地方（它通常不在旧代码中，因为它们是服务器上唯一的客户端）。生产中的第一天发送电子邮件，将客户专有数据不仅发送给客户销售代表，还发送给许多竞争对手的销售代表。在可能错过这一变化的所有地方中，这是最糟糕的地方。它不仅损害了我们与第一个客户的关系，而且还损害了所有错误获得其他客户信息的客户。
还存在迁移数据的问题，单独的项目（没有应用程序将需要的代码更改）将需要数月，然后您已经考虑到客户端将在您进行和最终推送时添加数据由于新数据可能会遇到意外的打嗝。您可能还必须至少在周末关闭odl系统才能进行生产更改。
使用模式不会让它变得更容易，因为您必须调整代码以便为每个客户端找到正确的模式。当你改变某些标志时，你必须为每个单独的模式更改它，因此它往往会使数据库更难维护。
虽然我非常喜欢在一个数据库中拥有多个客户端，但是当您没有这样开始时，更改的风险极高且成本高昂。除非我有这些东西，否则我不会这样做：
Code in source control
Extensive Unit and regression tests
Separate dev, QA and prod environments
A process for client UAT testing
Extensive knowledge of how cloud computing and webservices works (everyone I know who has moved stuff to the cloud has had some real gotchas)
A QA department
Six months to one year time frame for the project
At least one senior data analyst on the team.