动态修补数据库
请原谅我的长期问题。我对设计有一个想法，可以在上面提出一些意见。这样做是个好主意吗？我应该知道什么是跌倒坑？还有其他更好的类似实现吗？
我的情况如下： 我正在重写连接到SQL 2008（以前是SQL 2005）服务器的Windows窗体应用程序。该应用程序是工程公司的“专家系统”，我们在其中存储有关建筑物的结构化数据。我们可以控制客户端软件的所有安装，没有外部客户或用户，它们都属于公司内部，并且可以信任他们不会对软件或数据库进行任何恶意操作。
当前的设计没有太多的表（大约10到20），但是其中一些表具有数百万个属于数百个构造的记录。到目前为止，系统性能还不错，但是随着我们不断突破设计极限，它开始下降。
作为重写的一部分，我正在考虑将数据库分为一个主数据库和几个“子”数据库，每个子数据库都描述一种构造。每个子数据库应具有相同的设计。这将消除我们今天看到的性能问题，因为存储在每个数据库中的数据将少于总数据量的百分之一。
我担心的是，现在不再需要维护一个数据库，而是要获取数百个必须保持最新状态的数据库。随着公司需求变更（您知道情况如何），该系统在不断发展，并且我们尽力减少变更的数量。因此，我们将需要一个系统来跟踪对系统所做的所有数据库更改，以便将其应用于子数据库。更新客户端应用程序不会有问题，我们对此方面拥有很好的控制权。
我正在考虑一个更改跟踪系统，在该系统中，我们将所有更改的数据库脚本存储在master数据库的表中。然后，我们可以为每个更改提供一个版本号，并可以在每个子数据库中存储一个当前版本号。当客户端程序连接到子数据库时，我们可以对照主数据库的当前版本号检查数据库的版本号，如果有补丁程序的版本号大于子数据库的版本号，我们将运行它们并进行更新子数据库为最新版本。
如我所见，这应该很好。对系统的任何更改将首先进行测试和验证，然后再提交为数据库的新版本。然后，该更改将在用户第一次打开数据库时应用于数据库。我想我们将在应用更改时以独占模式打开数据库，但是只要更改不是太频繁，这应该不是问题。
所以你怎么看？这样行吗？你们有没有做过类似的事情？我们应该废弃解决方案并转而使用整体系统吗？
问题来源于stack overflow
写回答
-
尽管我使用MySQL，但我在这里也遇到类似情况。每个数据库都有一个版本表，该表包含版本（简单地是一个整数）和该版本中已更改内容的简短注释。我使用脚本来更新数据库。每个数据库更改都可以在一个功能中进行，有时一个更改是由多个功能进行的。函数在函数名称中包含版本号。该脚本在数据库中查找最高版本号，并且仅按顺序应用具有较高版本号的功能。
这样可以轻松地更新数据库（只需添加新的更改功能），并允许我在必要时快速升级恢复的数据库（只需再次运行脚本）。
即使在此之前测试更改，也可以进行防御性更改。如果您在桌子上做了一些大的改动并且想要安全地玩：
def change103(...): "Create new table." def change104(...): """Transfer data from old table to new table and make complicated changes in the process. """ def change105(...): "Drop old table" def change106(...): "Rename new table to old table" 如果change104（）中出现问题（并引发异常），则可以简单地从新表中删除已转换的数据，修复更改函数并再次运行脚本。
但是我不认为在客户端连接时动态更改数据库是一个好主意。有时更改可能需要一些时间。并且访问数据库的软件应与数据库的架构匹配。您可以通过某种方式使它们保持同步。也许您可以分发新的软件版本，然后在客户端实际开始使用此新软件时要升级数据库。但是我还没有尝试过。
2019-11-18 18:01:35赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
