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

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

некоторые примеры, о которых я думаю:

  • дисконтированные типы финансирования старших лет университета
  • неиспользуемые валюты (например, итальянская лира)
  • названия исчезнувших стран (например, Австро-Венгрия, СССР)

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

может быть есть шаблон для этой проблемы.

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

  • Если старые данные затрудняют повседневную работу с огромной базой данных, разделение было бы полезно. Описание Oracle по этому вопросу здесь.

  • с точки зрения дизайнера таксономии медленно изменяющееся измерение дает некоторую справочную информацию.

9
database-design

11 ответов

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

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

4

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

CREATE TABLE Currency (CurrencyID NUMBER, CurrencyStartDate DATETIME, CurrentEndDate DATETIME)

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

2

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

1

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

общий шаблон должен иметь поле" релевантное от/до " datatime в записях. В этом случае исторические отчеты могут включать типы, относящиеся к данному периоду. (Более простым решением было бы логическое "устаревший" флаг на записях, но так как это не указывает, когда это было актуально, это не будет так полезно для исторического отчета.)

1

Это стандартная медленно меняющаяся проблема измерения. У вас есть SCD со статусом и / или диапазонами дат.

"каждый из них средств индивидуальной решение и трудно понять, что типы объектов нужно специальное обращение"

да. Сожалеть об этом. Вы должны проанализировать свои данные и подумать. Нелегко обойти эту часть мышления.

1

Я бы предложил разделить операционную систему и систему отчетности. Есть одна база данных для оперативного - онлайн система и другое для отчетности. (Может быть хранилище данных, или просто другое база данных) на основе того, насколько универсальной должна быть система отчетности.

периодически перемещать данные из операционной системы в систему отчетности. (частота зависит от характера вашей системе). Все исторические отчеты будут на основе базы данных отчетов. Онлайн база данных также будет содержать отчеты, но не (очень) исторических.

и, да. Вам нужно поддерживать даты или флаги в таблицах, чтобы решить, имеет ли элемент истек.

1

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

0

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

0

коммерческие СУБД (Informix, DB2, возможно Oracle, ...) иметь возможности секционирования или фрагментации, чтобы вы могли размещать разные данные в разных фрагментах, а оптимизатор запросов будет игнорировать фрагменты, которые ему не нужны. Иногда их можно использовать для размещения менее часто используемых данных в областях хранения, используемых только для архаичных данных. Преимущество этого заключается в том, что система занимается размещением (ОК, система плюс DBA), а приложения совершенно не обращая на это внимания.

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

0

Я нашел аналогичный вопрос:каков наилучший способ реализации мягкого удаления? работа с решением флага активности.

и вот еще один на флаги деятельность `активный’ флаг или нет? для mysql и postgresql.

на основе этих двух вопросов флаги активности и / или секционирование таблиц являются наиболее распространенными решениями проблемы.

0

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

0