VS
ну я если что, серьезно спросил...
с точки зрения логики я тогда не понимаю, причем тут первичный ключ и уникальный...
с точки зрения логики я тогда не понимаю, причем тут первичный ключ и уникальный...
Size: a a a
2020 October 21
VS
и второй момент, который довольно часто озвучивается в DV, а стоит ли raw/stage слой делать на DV?
MV
Коллеги, всем привет. Вопрос по Data Vault. У меня в источнике есть таблица, в которой одно поле является ПК, а второе УК. Следовательно, в хаб я помещаю оба этих поля и вычисляю хэш от их конкатенации. Однако, в других таблицах могут быть ФК на одно из этих полей, а не на оба. И когда появляется такая информация, я не могу без костылей в таблице линке вычислить хэш ключ (только по одному полю, которое является ФК). Как быть?
Пока я думаю разбить этот хаб на два (в одном ПК, в другом УК) соединить их линком и туда прицепить сателит. Есть ли более рациональные варианты?
Пока я думаю разбить этот хаб на два (в одном ПК, в другом УК) соединить их линком и туда прицепить сателит. Есть ли более рациональные варианты?
Владимир, хаб строится не от PK, и не от УК, он строится от логической сущности. Надо понять какую сущность вы собираетесь описывать и потом определять для нею натуральный ключ, который ляжет в хаб.
MV
Если просто совать всё что ни попадя в data vault, то толку от data vault никакого нет. Можете с тем же успехом хранить сырые данные или нормализовывать в третьей нормальной форме.
VS
ну в целом да, по сути это BDV
VP
ну я если что, серьезно спросил...
с точки зрения логики я тогда не понимаю, причем тут первичный ключ и уникальный...
с точки зрения логики я тогда не понимаю, причем тут первичный ключ и уникальный...
Вангую что речь о суррогатном ключе (ПК) + бизнес ключе (УК) в одной таблице. И наверняка некоторые в источнике ссылаются кто на первый ключ кто на второй
VS
составной, ПК как раз является сурогатным тогда
VS
и тут как раз сразу вопрос, а что это такое, случайно не историческая какая-либо таблица, в которой на сурогатник ввиде ПК вообще стоит забить
VK
и тут как раз сразу вопрос, а что это такое, случайно не историческая какая-либо таблица, в которой на сурогатник ввиде ПК вообще стоит забить
Сурогатник, но он используется как фк в других таблицах. Другое поле тоже сурогатник, но на него наложение уникальности сделали
VK
Владимир, хаб строится не от PK, и не от УК, он строится от логической сущности. Надо понять какую сущность вы собираетесь описывать и потом определять для нею натуральный ключ, который ляжет в хаб.
Спасибо) Как же трудно выцеплять эти сущности)
VS
Да, определяйте сразу сущности, тяжело по первой, потом как по маслу пойдет
VK
Я просто пытался всё это как-то автоматизировать, ибо создавать всё это в ручную - можно сойти с ума. Плясал как раз от pk, uk, fk
Но, похоже, это был очень плохой план)
Но, похоже, это был очень плохой план)
MV
Спасибо) Как же трудно выцеплять эти сущности)
Да, но это и есть основной труд создания модели. Хз про «как по маслу», зависит от областей сильно. Если у вас доменов много, то они могут быть очень разные
MV
Я просто пытался всё это как-то автоматизировать, ибо создавать всё это в ручную - можно сойти с ума. Плясал как раз от pk, uk, fk
Но, похоже, это был очень плохой план)
Но, похоже, это был очень плохой план)
Плохой, потому что выбор PK/UK/FK не всегда бывает корректным.
PK - это просто один из candidate key, которых может быть много. Часто это суррогатник типа сиквенса, но бывают чудесные совершенно решения архитекторов иногда.
UK - вообще могут не ставить (нафига?) или ошибаться с их расстановкой.
Я, конечно, тоже могу перегибать палку. Может у вас там боги архитектуры данных базу дизайнили… Но в реальной жизни я такое редко вижу
PK - это просто один из candidate key, которых может быть много. Часто это суррогатник типа сиквенса, но бывают чудесные совершенно решения архитекторов иногда.
UK - вообще могут не ставить (нафига?) или ошибаться с их расстановкой.
Я, конечно, тоже могу перегибать палку. Может у вас там боги архитектуры данных базу дизайнили… Но в реальной жизни я такое редко вижу
VK
Плохой, потому что выбор PK/UK/FK не всегда бывает корректным.
PK - это просто один из candidate key, которых может быть много. Часто это суррогатник типа сиквенса, но бывают чудесные совершенно решения архитекторов иногда.
UK - вообще могут не ставить (нафига?) или ошибаться с их расстановкой.
Я, конечно, тоже могу перегибать палку. Может у вас там боги архитектуры данных базу дизайнили… Но в реальной жизни я такое редко вижу
PK - это просто один из candidate key, которых может быть много. Часто это суррогатник типа сиквенса, но бывают чудесные совершенно решения архитекторов иногда.
UK - вообще могут не ставить (нафига?) или ошибаться с их расстановкой.
Я, конечно, тоже могу перегибать палку. Может у вас там боги архитектуры данных базу дизайнили… Но в реальной жизни я такое редко вижу
Да нет, нифига не боги)
Пошёл спрашивать, зачем тут это и это. Говорят, "ну, так исторически сложилось")
Пошёл спрашивать, зачем тут это и это. Говорят, "ну, так исторически сложилось")
MV
Основной принципип всех этих моделей - отвязать логику от вашего бизнеса. Чтобы когда бизнес поменялся, сущности остались. Так что это большой труд, очень тяжёлый.
MV
Сначала абстрагироваться, а потом сидеть херачить витрины «под заказчика» 🙈 perfect plan
VK
Сначала абстрагироваться, а потом сидеть херачить витрины «под заказчика» 🙈 perfect plan
Да, но похоже у меня уже всё пошло не по плану)
Спасибо) А есть какие-нибудь ещё хорошие источники по архитектуре кроме книги от создателя, не знаете?
Спасибо) А есть какие-нибудь ещё хорошие источники по архитектуре кроме книги от создателя, не знаете?
MV
Хм… Нет. Не знаю. Есть канал по архитектуре данных, может там подскажут. Я кроме спецификаций на волт и энкор читал только материалы конференций и копался в моделях ))