Версионность НСИ в БД
У нас почти все версионные справочники имеют дату в первичном ключе, соответственно, все запросы к ним включают подзапрос с отбором максимальной даты. В некоторых еще и дата окончания хранится (но не в ключе если природа записей подразумевает строгое ограничение по дате сверху. Хотя в одном из справочников используются и идшники, соответствующие метке времени, но с ним завязана довольно сложная система сущностей, так что не могу оценить, лучше это или хуже чем даты.
На предыдущей работе Р-Стайл у заказчика было требование, чтобы всё можно было посмотреть на предыдущую дату. Вообще всё.
Данные в базе хранились в виде
id-data-start_date-end_date
Для актуальных записей end_date проставлялся как 2999г. Если запись первая, то start_date ставился 1900г.
Выборка данных в этом случае проводится так
По факту интерфейс у данного решения работал не быстро, но я не уверен, что дело именно в архитектуре, а в не настройке базы или используемых программных компонент для интерфейса. Моя задача по этому делу была подготавливать данные для отчетов, при этом подразумевалось, что пользователь может посмотреть отчет как на сегодняшний день, так и за любой предыдущий. Архитектура БД, куда я заливал данные, обеспечила мне год ада. После чего меня это достало и я свалил.
Данные в базе хранились в виде
id-data-start_date-end_date
Для актуальных записей end_date проставлялся как 2999г. Если запись первая, то start_date ставился 1900г.
Выборка данных в этом случае проводится так
select * from t where <нужная дата> between start_date and end_date
По факту интерфейс у данного решения работал не быстро, но я не уверен, что дело именно в архитектуре, а в не настройке базы или используемых программных компонент для интерфейса. Моя задача по этому делу была подготавливать данные для отчетов, при этом подразумевалось, что пользователь может посмотреть отчет как на сегодняшний день, так и за любой предыдущий. Архитектура БД, куда я заливал данные, обеспечила мне год ада. После чего меня это достало и я свалил.
Ясно, такой вариант меня еще больше пугает, потому что between по типу дата будет медленнее работать по сравнению с номером версии.
У вас бизнес-версионность или техническая?
техническая
а что такое техническая? зачем технике версионность?
более правильно наверное технологическая
я помню, как ты писала нечто популярное по теории относительности. поэтому вопрос. у тебя никогда не было хотя бы смутного ощущения, что это "квадратное" время в некоторых ХД (где обе версионности поддерживаются одновременно) как-то напоминает СТО?
в SAP версионность и зависимость от времени разные понятия
версия - это, например, план, факт, прогноз (зависимость справочника счетов); ключ в поле таблицы
время - используется при нестандартных требованиях к историчности; например, "хочу видеть отчет таким, как он был n лет назад"; соответственно в ключ включается поле DATETO + не в ключ DATEFROM
в один момент времени может быть несколько версий
версия - это, например, план, факт, прогноз (зависимость справочника счетов); ключ в поле таблицы
время - используется при нестандартных требованиях к историчности; например, "хочу видеть отчет таким, как он был n лет назад"; соответственно в ключ включается поле DATETO + не в ключ DATEFROM
в один момент времени может быть несколько версий
Оставить комментарий
grnat
Подскажите правильный поход по организации версионности структуры бд.Есть куча справочников нормативной информации(меняющиеся не постоянно но и не редко есть модели основанные на данных из этих справочников.
По данным моделей записываются ретроспективные данные. Задача стоит проводить расчеты на этих моделях как на актуальных данных так и на ретроспективных для сравнения между собой.
Собственно как принято строить такую версионную структуру?
Статью на хабре(про модель Кимболла) прочел, но интересует как делают в общемировой практике.
Из предлагаемого подхода не нравится хранения справочников с составным уникальным ключом и хранения ретроспективных данных с указанием версии/ревизии. Какая то сильная перегруженность получается, особенно в случае пересечения большого кол-ва справочников.