![]() |
#8 |
Участник
|
Цитата:
Не надо придумывать себе проблемы, чтобы потом их героически преодолевать. С составными ключами слишком сложно работать. По любому будет "перекодировка" справочников при заливке из транзакционной базы Axapta в базу хранилища. Ну, и не надо "мудрить". Стандартный автоинкремент в качестве суррогатного ключа. Можно то же Idetntity или SequenceName, если речь идет о MS SQL. Если несколько клиентов Axapta должны рассматриваться как один клиент в отчете, то обязательно таблица перекодировки. Не надо пытаться как-то "разрулить" это в рамках одной таблицы. Отдельная таблица-справочник для хранилища и отдельная таблица-перекодировщик с кодами соответствия Axapta-хранилища. Вот в этой таблице-перекодировщике можно "изгаляться" как угодно... Примерно это выглядит так Справочник хранилища Id - identity - идентификатор записи для связи с другими таблицами хранилища AccountCode - код, под которым должна отображаться нужная сущность в отчете AccountName - название, которое должно отображаться в отчете (...) - прочие реквизиты справочника для формирования разрезов Ограничения Id - PrimaryKey AccountCode - альтернативный ключ. Дублирование запрещено! Таблица-перекодировщик AccountCode_DWH - код, под которым должна отображаться нужная сущность в отчете. Поле AccountCode в справочнике хранилища (DWH - Data Warehouse) DataAreaId - код компании в Axapta AccountCode - код Axapta (...) - прочие поля для однозначной идентификации записи в Axapta в таблице-перекодировщике никаких ограничений! Может дублироваться что угодно и как угодно! Соответственно, логика загрузки 1. По набору идентификаторов Axapta ищем нужный код в таблице-перекодировщике 2. По найденному альтернативному ключу ищем нужный код в справочнике хранилища
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Cardagant (2). |