动态修补数据库

请原谅我的长期问题。我对设计有一个想法，可以在上面提出一些意见。这样做是个好主意吗？我应该知道什么是跌倒坑？还有其他更好的类似实现吗？ 我的情况如下： 我正在重写连接到SQL 2008（以前是SQL 2005）服务器的Windows窗体应用程序。该应用程序是工程公司的“专家系统”，我们在其中存储有关建筑物的结构化数据。我们可以控制客户端软件的所有安装，没有外部客户或用户，它们都属于公司内部，并且可以信任他们不会对软件或数据库进行任何恶意操作。 当前的设计没有太多的表（大约10到20），但是其中一些表具有数百万个属于数百个构造的记录。到目前为止，系统性能还不错，但是随着我们不断突破设计极限，它开始下降。 作为重写的一部分，我正在考虑将数据库分为一个主数据库和几个“子”数据库，每个子数据库都描述一种构造。每个子数据库应具有相同的设计。这将消除我们今天看到的性能问题，因为存储在每个数据库中的数据将少于总数据量的百分之一。 我担心的是，现在不再需要维护一个数据库，而是要获取数百个必须保持最新状态的数据库。随着公司需求变更（您知道情况如何），该系统在不断发展，并且我们尽力减少变更的数量。因此，我们将需要一个系统来跟踪对系统所做的所有数据库更改，以便将其应用于子数据库。更新客户端应用程序不会有问题，我们对此方面拥有很好的控制权。 我正在考虑一个更改跟踪系统，在该系统中，我们将所有更改的数据库脚本存储在master数据库的表中。然后，我们可以为每个更改提供一个版本号，并可以在每个子数据库中存储一个当前版本号。当客户端程序连接到子数据库时，我们可以对照主数据库的当前版本号检查数据库的版本号，如果有补丁程序的版本号大于子数据库的版本号，我们将运行它们并进行更新子数据库为最新版本。 如我所见，这应该很好。对系统的任何更改将首先进行测试和验证，然后再提交为数据库的新版本。然后，该更改将在用户第一次打开数据库时应用于数据库。我想我们将在应用更改时以独占模式打开数据库，但是只要更改不是太频繁，这应该不是问题。 所以你怎么看？这样行吗？你们有没有做过类似的事情？我们应该废弃解决方案并转而使用整体系统吗？