Разработка процесса архивирования данных (SQL Server 2005)

Мы разрабатываем процесс архивирования набора записей на основе различных критериев, таких как дата, статус и т. д.

Упрощенный набор таблиц: Claim, ClaimDetails, StatusHistory (отслеживает изменения статуса претензии), Comments и Files

Среда: SQL Server 2005, ASP.Net MVC (.NET Framework v3.5 SP1)

Claim является основным объектом, и у него есть дочерние строки в упомянутых подтаблицах. Некоторые из них содержат детали, а другие используются для отслеживания изменений. В конце концов, на основании некоторых критериев Claim становится «готовым к архивированию», как описано выше. Проще говоря, заархивированные Claims будут идентифицированы из базы данных и обработаны по-разному в веб-приложении.

Вот самый простой вариант: (вид сверху)

  • Создайте скрипт, который помечает Claim "заархивированный" в db.
  • Архивную строку и ее дочерние строки можно либо оставить в одной таблице (установить флаг), либо переместить в другую таблицу, которая будет копией исходной.
  • В веб-приложении мы позволим пользователю фильтровать Claims на основе статуса архива.
  • В будущем может возникнуть необходимость "разархивировать" Claim.

Что мне нужно знать?

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

  2. Является ли своевременный запланированный сценарий SQL лучшим вариантом для этого сценария?

  3. Должен ли я рассмотреть возможность использования отдельных таблиц или просто добавить флаг «Архив» для каждой таблицы?

  4. Для рассмотрения производительности выбранного подхода - какая разница, если мы планируем иметь около 10 000 Claims и что, если это 1 миллион. Вкратце, пожалуйста, укажите подход с легкой и тяжелой нагрузкой.

  5. Мы храним файлы, загруженные физически на наш сервер - я думаю, что это может остаться как есть.

Примечание. Заявка может иметь любое количество дочерних записей во всех упомянутых таблицах, поэтому она становится n-кратной.

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


archive database-design sql-server-2005
person Hemant Tank    schedule 29.11.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вы можете найти хорошее обсуждение этой темы здесь и это еще один.

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

person kishore    schedule 21.12.2011
comment
Спасибо, но это больше похоже на ведение журнала БД при каждом редактировании. Мне нужно что-то, что поддерживает архив после того, как запись заархивирована, она становится доступной только для чтения, поэтому нет необходимости поддерживать несколько версий. Кроме того, речь идет о нескольких миллионах записей за 2-3 года. - person Hemant Tank; 21.12.2011
comment
Наличие флага «Архивировано» для каждой таблицы — это самое простое решение, но это не очень гибкий подход к любым будущим изменениям, которые могут возникнуть. Вы также должны учитывать, как часто архивные данные используются в ваших приложениях. Если к активным заявкам обращаются чаще, чем к заархивированным, то создание отдельной таблицы для заархивированных заявок повышает производительность, поскольку вы будете запрашивать небольшой набор данных. - person kishore; 21.12.2011