AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.12.2014, 20:47   #41  
Alex_K is offline
Alex_K
Участник
 
531 / 36 (3) +++
Регистрация: 07.02.2003
Цитата:
Сообщение от Cardagant Посмотреть сообщение
Затем, чтобы не получилось некоего "схлопывания" записей. Например. опять же с одинаковыми кодами. Выход - генерить собственный ключ на основе трёх полей.
Совсем не переносить составной ключ ведь нельзя.
HASHBYTES (Item_Id+DataareaID) будет неплохим аналогом бизнес-ключа измерения. По крайней мере, позволит аккуратно отрабатывать SCD. Если такой код назначать однократно и сохранять в InventTable, то это будет по Кимбаллу называться durable key. В таком случае, даже изменение кода номенклатуры не нарушит целостность данных в DWH.

Код компании заодно можно добавить в атрибуты измерения Номенклатура и получить level-based иерархию Компания-Номенклатура. По этому же атрибуту можно будет в кубике или BI-системе разграничить доступ к элементам измерения.

Но само собой, проблему унификации справочника это не решит. Тут действительно нужна или "взрослая" MDM или её самодельная реализация в аксе в виде таблиц соответствия.
Старый 10.12.2014, 15:01   #42  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Вот с использованием HASHBYTES никак не соглашусь. В зависимости от алгоритма это минимум 16 байт. Мне думается, что уж гораздо проще использовать какой-нибудь другой способ генерации уникального значения с размером поменьше.
Старый 10.12.2014, 15:47   #43  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Вот с использованием HASHBYTES никак не соглашусь. В зависимости от алгоритма это минимум 16 байт. Мне думается, что уж гораздо проще использовать какой-нибудь другой способ генерации уникального значения с размером поменьше.
Можно конвертировать в bigint, тогда ключ будет 8 байт.
Старый 10.12.2014, 17:54   #44  
Alex_K is offline
Alex_K
Участник
 
531 / 36 (3) +++
Регистрация: 07.02.2003
Если в DWH мы, как положено, используем суррогатные ключи, то размер бизнес-ключа (или durable-ключа) значения не имеет. Плюс-минус десяток микросекунд на запись при выполнении ETL-процесса - по сравнению с загрузкой/процессингом длиннющей таблицы фактов сущий пустяк.

Мы MD5 использовали как в качестве ключа, так и для того, чтобы проверять изменения хоть в таблице измерения, хоть в фактах. Можно лукапить только поле хэша вместо проверки каждого поля по отдельности.

Последний раз редактировалось Alex_K; 10.12.2014 в 17:58.
Старый 10.12.2014, 18:06   #45  
Cardagant is offline
Cardagant
Участник
 
317 / 54 (2) ++++
Регистрация: 11.10.2011
Цитата:
Сообщение от Alex_K Посмотреть сообщение
Если в DWH мы, как положено, используем суррогатные ключи, то размер бизнес-ключа (или durable-ключа) значения не имеет. Плюс-минус десяток микросекунд на запись при выполнении ETL-процесса - по сравнению с загрузкой/процессингом длиннющей таблицы фактов сущий пустяк.

Мы MD5 использовали как в качестве ключа, так и для того, чтобы проверять изменения хоть в таблице измерения, хоть в фактах. Можно лукапить только поле хэша вместо проверки каждого поля по отдельности.
А как Вы использовали HASHBYTES() для проверки изменения числовых значений фактов?

Не в строку же конвертировали?
Старый 11.12.2014, 08:57   #46  
Alex_K is offline
Alex_K
Участник
 
531 / 36 (3) +++
Регистрация: 07.02.2003
Цитата:
Сообщение от Cardagant Посмотреть сообщение
А как Вы использовали HASHBYTES() для проверки изменения числовых значений фактов?

Не в строку же конвертировали?
Ну было дело... Конвертировал... Только не hashbytes(), а какой-то другой случай с бинарным типом данных.
А вообще, в SQL Server 2008 и выше есть побитовые операторы.
Сравнил, если результат равен 0 - налево, иначе - направо.

Вообще, "зависит от...". Если важно иметь возможность (мало ли зачем) видеть значение ключа/атрибута глазками, лучше сразу привести к строке и сохранить в таблице. Опять же, стоимость хранения и чтения в запросах для такой строки невелика, да и использоваться это поле будет только в ETL.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Проведите ликбез по DAX, плиз ) Andey DAX: Программирование 3 23.05.2012 12:27
Создание снимков изменений в базе данных Ace of Database DAX: Программирование 17 01.11.2011 12:34
aEremenko: Тестирование производительности в DAX 4.0 Blog bot DAX Blogs 0 12.03.2008 16:05
dax-lessons: Active directory in Axapta Blog bot DAX Blogs 0 27.08.2007 23:00
Как настроить репликацию таблиц Аксапта в хранилище данных для OLAP max_spbti DAX: Функционал 4 28.06.2004 10:32
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:42.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.