Я изучаю использование методологии datavault 2.0. Я понимаю причины хеширования и пытаюсь его применить. Я хотел бы применить это на этапе «постановки» хранилища данных, а не загружать его в DV.
Если в таблице есть бизнес-ключ, то его легко просто применить к этой таблице (возможно, она станет концентратором). Но есть таблицы, такие как «orderdetail» (которые, вероятно, становятся ссылками), которые имеют несколько ссылок на другие элементы через суррогатный ключ.
Должна ли промежуточная таблица содержать как суррогатную последовательность для каждого внешнего ключа, так и хэш для указанного объекта BK?
Пример: если у меня есть таблица заказов с суррогатной последовательностью customerId, но в таблице клиентов есть ссылка CUST-000xxx, которая используется в качестве BK, должен ли я выполнить «соединение» между заказом и клиентом, чтобы разрешить «CUST-000xxx» чтобы я мог его хешировать и включить в промежуточную таблицу заказа?
Я думал, что это потенциально может быть решено при загрузке данных в DV из промежуточной области, но ссылка на клиента может не существовать в промежуточной области в тот конкретный момент времени, потому что заказ может быть просто новым заказом для существующий клиент, который не изменился.
DV 2.0 указывает, что вся эта работа с хешами делается для повышения производительности и простой параллельной загрузки данных без дорогостоящих поисков в самом DV. Отсюда вопрос, как это обычно решается.
Пример добавлен сюда:
order - orderid - customerid - order_ref - идентификатор продавца
клиент - customerid - customer_ref
person - personid - full_name - логин
Чтобы заполнить порядок, я должен выполнить соединение в исходной базе данных следующим образом:
SELECT
hash_func(o.order_ref) as hash_key_order,
hash_func(c.customer_ref) as hash_key_customer,
hash_func(p.login) as hash_key_person,
o.orderid,
c.customerid,
p.login
FROM
order o inner join customer c on o.customerid = c.customerid
inner join person p on o.salespersonid = p.personid
или это разрешение для внешних ключей, разрешенное в хранилище данных, поэтому запрос проще, например:
SELECT
hash_func(o.order_ref) as hash_key_order,
o.orderid,
c.customerid,
p.personid
FROM
order o
Мне это непонятно. Насколько я понимаю, путем хеширования можно избежать дорогостоящих поисков, поэтому отсутствие генерации хэша при постановке для внешних ключей в противном случае не повлияет на производительность?
