使用多年后更新数据库

Question

编辑 1：最后的故事示例

多年前，我们创建了表格来计算我们的盒子里有多少产品。

有两个简单的表：

product (

    code VARCHAR(16) PK,

    length INT,

    width INT,

    height INT

)

box (

    pkid INT IDENTITY(1,1),

    barcode varchar(18),

    product_code VARCHAR(16) FK,

    quantity INT

)

还有两个相关的类：

public struct Product

{

    public string Code { get; set; }

    public int Length { get; set; }

    public int Width { get; set; }

    public int Heigth { get; set; }

}

public struct Box

{

    public int Id { get; set; }

    public string BarCode { get; set; }

    public Product Product { get; set; }

    public int Quantity { get; set; }

}

多年后，我们需要将多个不同的产品放在同一个盒子里，所以我们现在需要这个：

product (

    code VARCHAR(16) PK,

    length INT,

    width INT,

    height INT

)

-- box changed

box (

    pkid INT IDENTITY(1,1),

    barcode varchar(18)

)

-- stock created

stock (

    box_pkid INT M-PK FK,

    product_code VARCHAR(16) M-PK FK,

    quantity INT

)

和这个：

public struct Product

{

    public string Code { get; set; }

    public int Length { get; set; }

    public int Width { get; set; }

    public int Heigth { get; set; }

}

public struct Box

{

    public int Id { get; set; }

    public string BarCode { get; set; }

    public Dictionary<Product, int> Content { get; set; } // <-- this changed

    public int Quantity { get; set; }

}

但多年后，我们有很多代码，可能在一些黑暗的地方重复，是离开合作者留下的。我是实习生，所以请教一下我以后的经历，以免以后遇到这种情况。

更新我们的架构并保持数据完整性安全的解决方案是什么？即使数据库中有数百万行？

示例： 2014 年，我们需要在一个盒子中存放 10 本罗密欧与朱丽叶书籍。如果我们有一些哈姆雷特的书，我们就会把它们放在另一个盒子里。罗密欧与朱丽叶的所有 10本书都是“相同”的产品（相同的封面、相同的内容、相同的参考文献）。

今天，我们想将不同的莎士比亚书籍存放在同一个盒子里。或者可能是不同的爱情书籍。甚至罗密欧与朱丽叶的书籍和小雕像？将不同的产品放在一起：我们应该改变box table和Box class，不是吗？

Answer 1

你有很多挑战；我会将他们分成两个高级别的小组。首先，如何在代码级别更改应用程序，其次，如何将数据从旧模式迁移到新模式。你如何改变你的代码？第一个问题是：您能否 100% 确定您列出的类是访问和修改数据的唯一方式？是否有任何触发器、存储过程、批处理作业或其他应用程序？除了通过浏览数据库架构工件和代码库之外，我不知道有什么方法可以找到这一点。在您“自己的”应用程序中，您有一个选择。扩展通常比修改界面更好。实际上，这意味着不是更改公共Product Product { get; set; }签名来处理字典，而是保留它并添加public Dictionary<Product, int> Content { get; set; }- 如果您可以保证旧方法仍然有效。这意味着有限地重写您的类的所有依赖项 - 您只需要担心需要了解一个盒子中可能有 1 个以上产品的客户。这允许您遵循“很多小的更改，但现有代码继续工作”的模型；你可以通过功能切换等来管理它。它的风险要低得多 - 所以这里的教训是“设计你的解决方案对扩展开放，但对改变封闭”。在这种情况下，这似乎是不可能的 - “set”方法可能没问题（您可以将其默认为“one product in a box”解决方案），但是“get”方法没有优雅的处理方式一个盒子里有超过 1 个产品的情况。如果这是真的，您更改类，并查找您的代码无法编译的所有实例，并遵循依赖链。例如，在典型的 MVC 框架中，在这种情况下，您将更改模型；这应该会导致控制器报告编译错误。在解决该错误时，您几乎肯定会修改控制器方法的签名。这反过来应该打破这种看法。所以你遵循那个链条；这样做意味着您的架构更改将成为“大爆炸，全有或全无”的版本。这通常会给所有相关人员带来压力......你如何释放你的变化？这在很大程度上取决于您选择了两个选项中的哪一个。@gburton 的回答涵盖了数据库步骤；这些在两个代码选项中都是必需的。第二个挑战是发布软件的新版本；例如，如果它是桌面客户端，则必须确保所有客户端在数据库更改的同时更新。这（通常）很可怕。如果它是一个 Web 应用程序，它通常会更容易一些 - 更少的客户端机器需要担心。

Answer 2

安全地更新遗留系统是一个经典问题。我从你的帖子中猜测，没有一个很好的数据库安全开发副本，或者至少一个是最新的，或者你已经有了一个可以在这里申请的过程。即使您显然使用的是 MS SQL Server，我还是以一种系统不可知的方式编写了这篇文章。关键是要小心谨慎，并确保在出现问题时永远不会 100% 卡住。备份旧数据库。确保您知道如何在不破坏任何内容的情况下执行此操作。将该备份还原到新位置。制定测试计划（这可能是工作中最长的部分）对数据库的新副本进行更改（不要触摸实时副本）运行您的测试计划以确保没有任何问题。如果第 5 步显示一些错误，您只需解决它们。一旦完成，你就有了可怕的部分。备份恢复练习在这里至关重要。备份实时数据库（您之前的备份可能已过时。您希望备份尽可能新鲜以减少数据丢失）运行备份恢复练习以 100% 确保您可以恢复将更改应用到实时数据库重新运行你的测试许多数据库引擎可以将数据库恢复到单个事务。如果可能，请考虑在步骤 6 中使用该过程。如何实现这一点将是一个单独的问题。