Какой шаблон проектирования версий вы бы рекомендовали

У меня есть требование построить "управление версиями" в приложении, и мне было интересно, как лучше всего подойти к нему.

У меня есть общий шаблон:

Модель A имеет множество B

При обновлении атрибуты A должны быть версиями и связанные с ним объекты (B) также должны быть версиями. Таким образом, приложение отобразит текущую версию A, но также должно быть возможно просмотреть предыдущие версии A и связанных с ним объектов.

Я хотел бы использовать хранилище документов, но это только часть приложения и наличие хранилища doc и базы данных отношений станут более сложными.

Я рассмотрел использование звездной схемы, но до того, как я прогрессировал, мне было интересно, существует ли шаблон проектирования, охватывающий эту проблему?

Этот вопрос склонен к решению проблемы хранения версий связанного объекта в реляционной базе данных. Там, где есть неотъемлемая потребность в возможности эффективно запрашивать данные (например, сериализация объекта будет недостаточной).

Обновление: что я думал/реализовал, но хочу узнать, является ли "лучшим способом" 

,---------. 1      * ,--------.
| Model A |----------| Model B|
`---------'          `--------'
|PK       |          | a_id   |
|b_version|          |version |
|version  |          `--------'
`---------'

Где бы я дублировал модель A и все связанные B и увеличивал атрибут версии. Затем сделайте выбор, чтобы присоединиться к B через b_version и b.version. Просто интересно, можно ли это сделать лучше.

Ответы

Ответ 1

Я не думаю, что для управления версиями нет определенного шаблона дизайна GoF, поскольку существует множество его реализаций.

Самая простая реализация управления версиями - это связанный список объектов. Где каждый node в списке представляет собой новую ревизию того, что является версией объекта. Для экономии места вы также реализуете какой-то diff, который показывает, какая разница между версиями. Таким образом, вы можете хранить diff в базе данных, но также и конечную версию объекта версии, поскольку система управления версиями должна иметь возможность выводить версии между ними.

Схема базы данных может в основном выглядеть примерно так (этот шаблон можно увидеть в большинстве вики-систем):

+--------------------+ 1     * +-----------------------------+
| VersionableObject  |---------| Diff                        |
+--------------------+         +-----------------------------+
| lastStateContent   |         | difference                  |
| originalAuthor     |         | revision                    |
| #dates and whatnot |         | # userId, dates and whatnot |      
+--------------------+         +-----------------------------+

Если вы хотите перейти на хардкор с ветвлением и другими вещами, которые вы, возможно, захотите рассмотреть, посмотрите DAG, что является тем, что современные системы управления версиями использовать.

Теперь, если мы расскажем о вашем примере целую массу объектов, которые необходимо сохранить в конфигурациях. То есть мы должны выбрать ревизии объектов, которые мы хотим для модели. Это означает, что у нас есть много-много отношений (которые решаются с помощью промежуточной таблицы), примерно так:

+---+ 1   * +---------------+ 1   * +-----------------+ *   1 +-------+
| B |-------| Diff          |-------| ModelSelection  |-------| Model |
+---+       +---------------+       +-----------------+       +-------+
            | revisionNo    |       | {PK} configId   |
            | {FK} configId |       | {FK} modelId    |
            +---------------+       +-----------------+

Надеюсь, это поможет.

Ответ 2

У Мартина Фаулера есть хорошие статьи о шаблонах дизайна, основанных на времени/версии, - определенно стоит посмотреть:

http://martinfowler.com/eaaDev/timeNarrative.html

Ответ 3

Я решил эту проблему в рельсах, используя плагин acts_as_versioned. Когда вы применяете его к модели, она предполагает наличие model_name_version в дополнение к таблице model_name. Каждый раз, когда модель сохраняется, старая версия вместе с меткой времени копируется в таблицу model_name_version.

Этот подход позволяет управлять размером таблицы модели, сохраняя при этом поиск в предыдущих версиях. Я не уверен, что плагин обрабатывает цепочку, которую вы хотите из коробки, но ее было бы сложно добавить.

Ответ 5

Как насчет сохранения моментального снимка XML базы данных, который вы хотите изменить? А затем сможете изменить состояние базы данных?