你会推荐什么版本设计模式？ [英] What versioning design pattern would you recommend
问题描述
我有要求将版本控制构建到应用程序中，并且想知道如何最好地处理它。
I have a requirement to build 'versioning' into an application and was wondering how best to approach it.
我有这个一般模式：
模型A有很多B的
在更新时，需要对A的属性进行版本控制，并且其关联的对象（B）也需要进行版本控制。因此，应用程序将显示当前版本的A，但也必须查看A及其关联对象的以前版本。
Where on update the attributes of A need to be versioned and its associated objects (B's) also need to be versioned. So the application will display the current version of A, but it must also be possible to view previous versions of A and its associated objects.
我想使用文档然而，这只是应用程序的一部分，并且具有文档存储和关系数据库将引入更多的复杂性。
I would like to use a document store however this is only a portion of the application and having a doc store and a relation database would introduce more complexity.
我已经考虑使用星型模式，但在进度之前，我想知道是否有一个设计模式浮动解决这个问题？
I have considered using a star schema, but before I progress I was wondering if there is a design pattern floating around tackling this problem?
此问题倾向于解决将关联对象的版本存储在关系数据库中的问题。如果有固有的需要能够有效地查询数据（即序列化对象不够）。
This question is slanted towards resolving the issue of storing the versions of an associated object in a relational database. Where there is an inherent need to be able to effectively query the data (ie serializing object won't suffice).
更新：我在想什么/已经实施，但想看看是否是更好的方式
Update: What I was thinking/have implemented but want to see if the is "a better way"
,---------. 1 * ,--------.
| Model A |----------| Model B|
`---------' `--------'
|PK | | a_id |
|b_version| |version |
|version | `--------'
`---------'
我将复制模型A和所有关联的B并增加版本属性。然后通过b_version和b.version进行选择以加入B。只是想知道这是否可以做得更好。
Where I would be duplicating model A and all the associated B's and incrementing the version attribute. Then doing a select to join the B's via b_version and b.version. Just wondering if this can be done better.
推荐答案
我不认为版本控制中没有特定的GoF设计模式本身因为它存在许多实现。
I don't think there is no specific GoF design pattern per se for versioning because there exists many implementations of it.
最简单的版本控制实现是一个对象的链表。其中列表中的每个节点都是可版本化对象的新版本。为了节省空间，您还可以实现某种差异，以显示修订版本之间的区别。这样，您可以将diff存储在数据库中，也可以存储版本控制对象的最终版本，因为版本控制系统应该可以导出版本之间的版本。
The most simple implementation of versioning is a linked list of objects. Where each node in the list is a new revision of whatever the versionable object is. To save space you also implement some kind of a diff that shows what the difference is between the revisions. That way you can store diffs in the database, but also the final version of the versionable object since the version control system should be able to derive the versions in between.
数据库模式主要看起来像这样（你可以在大多数wiki系统中看到这种模式）：
The database schema could principally look something like this (you can see this pattern in most wiki systems):
+--------------------+ 1 * +-----------------------------+
| VersionableObject |---------| Diff |
+--------------------+ +-----------------------------+
| lastStateContent | | difference |
| originalAuthor | | revision |
| #dates and whatnot | | # userId, dates and whatnot |
+--------------------+ +-----------------------------+
如果你想用分支和东西去硬核，你可能想要请考虑看看现代分布式版本控制系统使用的 DAG 。
If you want to go hardcore with branching and stuff you might want to consider have a look at DAG which is what modern distributed version control systems use.
现在，如果我们谈论你的例子，需要保存在配置中的一大堆对象。即我们必须挑选我们想要的模型的对象的修订。这意味着我们有许多关系（这是通过中介表解决的），类似于这样：
Now if we talk about your example a whole slew of objects that needs to be saved in configurations. I.e. we have to pick out the revisions of objects that we want for the model. It means we have a many to many relationship (which is solved with an intermediary table), sort of like this:
+---+ 1 * +---------------+ 1 * +-----------------+ * 1 +-------+
| B |-------| Diff |-------| ModelSelection |-------| Model |
+---+ +---------------+ +-----------------+ +-------+
| revisionNo | | {PK} configId |
| {FK} configId | | {FK} modelId |
+---------------+ +-----------------+
我希望这有帮助。
这篇关于你会推荐什么版本设计模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
