PG
Решаешь, как архитектор
Size: a a a
2020 June 09
Н
само собой. я вот сижу и думаю - нахрена мне вольт - когда я могу анкормоделинг сделать
Н
с его knot для подобных случаев
PG
В анкоре тоже надо было думать об этом, судя по статьям, но там для выстраивания отношений и связующих сущностей
Н
да, верно
Н
только в атрибутах для каждого клиента я храню идентификатор knot а не слово муж или жен
Н
вот и спрашиваю, с точки зрения построения дата вольта - нужно хранить идентификаторы с ссылкой на справочник (что странно) или таки слова муж/жен
PG
Смотря про что ты говоришь. Если про сателлит, то в нем хранится ид хаба, а не наоборот
DT
любая методология в т.ч. data vault ограничивается здравым смыслом. Какой плюс от создания хаба и сателлита из справочника полов вместо хранения в сателлите клиента айди пола?
DT
А если дальше идти еще, то какой смысл создания айди для справочника полов, когда можно хранить сразу код типа ‘M’, ‘F’?
DT
я никогда не понимал подход “методология ради методологии”. Любая методология - это набор идей, которые ты как архитектор можешь в разной степени использовать при построении своей модели
PG
Для общих справочников в DV есть отдельная сущность, сейчас не вспомню, но модель все же шире, чем хаб сат линк
VS
это тот же хаб
DT
Сам автор эволюционирует, и признает, что делать срез данных по сателлитам, которые историзируются только по полю “snapshot_dttm”, - это больно, и вместо этого предлагаю from и to dttm, или поинт ин тайм таблицы
DT
это тот же хаб
хаб не содержит описательной атрибутики, а справочник - содержит
VS
хаб+сат
VS
по сути, тот же хаб
VS
вот только делать такое ради пола нет смысла
DT
ес-ес
Н
Не привязывайтесь к полу, он для примера