我有一个客户目前正在使用的桌面应用程序，每个客户都可以访问他们自己的本地网络数据库。 我的经理决定最好合并这些数据库并且只有一个。然后，所有客户端将通过位于云上的 Web 服务访问该数据库。在我们做出这个决定之前，我想权衡利弊。 我们的一个选择是在每个表中都有一个 ClientID，这将导致每个表都有一个复合键。
我听说另一种选择是使用模式。请告知模式方式将如何工作，与在每个表中都有一个复合键相比，这是最好的方式。 谢谢。
【问题讨论】：
标签： sql database merge schema composite-primary-key
这是一项非常困难且耗时的任务。您将需要已经构建了广泛的回归测试，因为发生故障的风险是巨大的。
让我告诉您一个客户的故事，该客户在一个单独的服务器上拥有一个单独的数据库，该数据库与另一个包含许多客户端的数据库合并。进行所有更改以转换数据需要几个月的时间。一切看起来都很好，它被推到了刺激之下。不幸的是，开发人员错过了一个需要引用客户端 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.
【讨论】：