问在prem上不同位置连续模式+数据升级的理想状态模式最佳实践

EN

不过，我想看看博客/文章中关于那些这样做的人的文章，这样我就可以把我的工作引用到其他人身上，这些人在/甚至是github回购之前也是这样做的：

我有一个项目的应用程序是20年前，主要是90%部署在客户网站。每个客户都有不同的版本，每个客户都对数据库进行了自己的自定义。我们的愿望是为更新的客户以及许多其他新的需求发展到一个基于云的系统。该系统还具有多个“实时”版本，例如34.54版本是活动版本，41.33版本都是维护的。因此，34.54的顾客将选择34.55而不是41.34。

该系统使用内部开发的迁移系统，它读取当前版本，然后只执行更新的sql以进行升级。这是数以万计的sql代码，没有一个写过这段代码的人还在问数以百计的问题“为什么”。

目标系统是NetCore EF，它显然具有迁移的形式。

我注意到的是，在许多地方，知道实际模式是否正确是很糟糕的，因为它需要在SSMS中手工运行每个sql文件，以了解是否按正确的顺序执行。这是因为它不仅改变了模式，还改变了内容(而且表和数据的数量更复杂)。根本原因分析需要很长时间才能最终确定客户自己改变了FK。

我开始写一些东西，而不是定义一个“想要的模式”(慢慢地)，这似乎很好地确保现有的安装具有所有正确的表、索引、外键、约束、枚举表内容、视图、存储过程、主键等等。这也是因为这减少了迁移的数量，例如更改pk或更改fk或更改列等。

因此，这可以一次又一次地运行，每次检查“一切”是否正常，如果没有纠正的话。

我所做的是大致做到这一点(跳过一些东西，如永久删除等)(同时检查是否存在)。它包含如果不存在，还包括删除，如果一个对象在过去创建了很长时间，在过去被删除了很长时间。

• 首先，我创建了所有的模式
• 第二，我运行“版本”(因此，系统所需的更改比使用sql迁移部分指定的版本更早)

然后是独立于版本和表定义的非迁移内容，因为它最终可能不是可临时的，而是每个表的特定的。这减少了“迁移”中的内容数量。

• 然后创建定义中只有1列的表本身。
• 然后，我删除每个表的规格说明的所有FK表
• 然后我删除所有索引等等，删除pk，
• 然后，我检查并更新每一列的大小、默认值、null等(可能有未处理的异常，但这些异常在上面的“版本”中)。
• 然后我创建PK
• 然后创建索引(拖放或表名)、约束等。
• 然后，通过检查每条记录的期望值(包括翻译)来填充enum表。
• 然后我创建FKS
• 然后我在层中创建视图(以后依赖于其他视图的视图等等)
• 然后创建存储过程。
• 然后通过删除和更新执行特定数据的加载。

我遗漏了一些部分，但大多数以上的部分现在导致能够一次又一次地运行它，并确保模式和所有特定于客户的数据都是正常的，所有必须通过“迁移”的东西仍然可以通过“版本”工作。

这就省去了一些头痛和问题，因为知道模式实际上就是模式，因为随着大量问题和but的出现，我们不知道模式是什么特定的客户，所以我们正在标准化，但这也不再需要迁移文件，即数千行，每次更改都需要新的迁移。

我知道人们可能会对此有一些反对意见，比如需要更长的时间来编写自己想要的东西，以及在需要进行升级时再次检查和创建所有这些，都需要“时间”来运行。但我正在寻找一个更加权的意见/博客等反对这一点。

我现在看到的一个优势是，它给了我关于这个数据库实际存在的背景信息，因为没有人在这里工作过了。因此，它让我有意识地想每一个表，fk，索引等，同时做这个和记录每一个。

(仍然可以正常使用迁移)

然而，现在：

不过，我想看看博客/文章中的人谁做了同样的，以便我可以参考我的工作，与其他人谁也走上了这个方向，并可能利用这一点。

例如，我通过C#代码运行这一操作，该代码以层方式执行上面的操作，并在每个项的每个表中都有一个sql文件。不过，我可以将信息(表、pk、列、pks、索引等)集中在一个定义中，并让系统确定可维护性的顺序，因为这将使开发人员更容易维护这些文件，这些文件开始闻起来可能已经在某个地方了，例如github，但我现在仍然使用SQL纯，因为这允许开发人员在SSMS中复制和粘贴代码以测试它。有了定义文件，这将更难测试。