Лучшая практика для проверенных сущностей? - PullRequest
1 голос
/ 19 июля 2009

Добрый день,

В настоящее время я нахожусь на очень ранней стадии нового проекта, написанного на .Net и использующего Entity Framework для сохранения / хранения данных. Одной из требуемых функций является возможность «версии» определенных типов моделей. Например. одна модель - это одно «Требование», которое будет иметь n «Версий требований», в основном имея возможность вернуться в историю / жизненный цикл этого конкретного экземпляра «Требования». Единственная вещь, которая должна быть статичной во всех ревизиях, - это «ID», все остальное абсолютно изменчиво в течение всего срока действия требования.

Теперь вопрос в том, должен ли я "просто" создать отношение 1: n между требованием >> RequirementVersion? Другие функции требуют возможности полностью восстановить старые состояния, чтобы быть текущим / самым последним, должна быть возможность иметь младшую и основную версию (изменения) и тому подобное, и, наконец, что не менее важно, способность создавать «Базовую линию» через набор требований с последней версией для возврата к этой конкретной базовой линии в более поздний момент времени и отображения всех включенных версий Requirement?

Это должно масштабироваться до пары миллионов записей требований, каждая из которых имеет пару тысяч ревизий ... именно поэтому я спрашиваю ... масштабирующий аспект простых отношений 1: n и т. Д.

Кто-нибудь делал что-то похожее и, может быть, какие-то предложения / лучшие практики и т. Д., Касающиеся версионирования / базового уровня и т. Д.?

Привет и спасибо, -Jörg

1 Ответ

0 голосов
/ 19 июля 2009

Это зависит от того, сколько данных имеет каждое требование.

Если Требование имеет большие поля (например, Описание Требования).

  1. Вы, вероятно, хотели бы вместо версии версии полей, а не само требование. К сожалению, кажется, что с Entity Framework нет простого способа справиться.
  2. Другое решение (мы сделали это для CMS) состоит в том, чтобы иметь отдельные таблицы для Требования и для Требования. Таким образом, в результате вы получите RequirementVersions и RequirmentDescriptionVersions.

Если Требование достаточно мало, вы можете использовать Требование >> Требование версии. В большинстве случаев у вас не будет значительного прироста данных, особенно вы можете использовать сжатие SQL2008.

...