T87,

Не обращайте на это внимание, ребрендинг крайне не частое явление, и новый продукт, который является копией старого (но с новым брендом), будет в 99% заведен именно как новый продукт, а не версия.

Или вы планируете хранить версии и при ошибках ввода?

Подниму темку:

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

Почему:
- в первичной системе возможны ошибки и при их исправлении в первичке - в ХД останутся плохие данные
- etl-процесс может упасть, и починен может быть только, скажем, завтра, значит вся относительно корректная историчность летит в Тартар

Имхо, либо SCD2 полностью берется из первичной системы, либо в ХД генерятся только логи, которые однозначно запрещено использоваться при расчетах в DDS.

Ваше мнение?

А как вы корректно обработаете изменение SCD0 в источнике, если у вас в ХД эта сущность идет в виде SCD2?
Правка источника заключается просто в исправлении ошибки, "которая всегда была". И естественно, что человек, который вносил исправления в первичке - может совсем не знать о ХД и о том, что там нужно тоже поправить справочник.


Voyager_lan,

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

То есть как-то так:
- Источник:Справочник SCD0
...
- DDS:Справочник SCD0 (может использоваться где угодно в расчетах)
--- DDS:Лог справочника в любом виде (только для разбора всяких сложных ситуаций, в расчетах не используется)

Сейчас работаю с ХД, в которой реализована SCD2 при отсутствии историчности в источнике - это ппц, одни заявки на изменение периодов привязок.