【问题标题】:Best Practice for Versioned Entities?版本化实体的最佳实践?
【发布时间】:2009-07-19 14:27:37
【问题描述】:

下午好,

我目前处于一个用 .Net 编写并使用实体框架进行数据持久性/存储的新项目的早期阶段。所需的功能之一是能够“版本”某些模型类型。例如。一个模型是一个“需求”,它将具有 n 个“需求版本”,基本上可以返回该特定“需求”实例的历史/生命周期。唯一必须在所有修订中保持静态的是它的“ID”,其他所有内容在需求的整个生命周期中都是绝对可变的。

现在的问题是,我是否应该“简单地”在 Requirement >> RequirementVersion 之间创建 1:n 关系?其他功能需要是完全恢复旧状态成为当前/最新状态的可能性,必须有能力拥有次要和主要版本(更改)等,最后但并非最不重要的是能够创建一个“基线”跨越具有最新版本的需求集合,以便稍后返回到该特定基线并显示所有包含的 RequirementVersions?

这必须扩展到几百万条需求记录,每个需求记录都有几千个修订版..这就是我特别问的原因..简单的 1:n 关系的缩放方面等。

有没有人做过类似的事情,也许还有一些关于版本控制/基线等的建议/最佳实践等?

干杯,谢谢, -约尔格

【问题讨论】:

    标签: .net versioning revision database-versioning


    【解决方案1】:

    这取决于每个需求有多少数据。

    如果需求有很大的字段(例如需求描述)。

    1. 您可能希望对字段进行版本化,而不是对需求本身进行版本化。不幸的是,似乎没有简单的方法来处理实体框架。
    2. 其他解决方案(我们为 CMS 执行此操作)是为需求和需求描述分别设置表格。因此,您将拥有 RequirementVersions 和 RequirmentDescriptionVersions。

    如果 Requirement 足够小,您可以使用 Requirement >> RequirementVersion。在大多数情况下,您不会有显着的数据增长,尤其是您可以利用 SQL2008 压缩。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-28
      • 2014-01-02
      • 1970-01-01
      • 2010-10-11
      • 2015-12-10
      相关资源
      最近更新 更多