1c 8.2 УПП
MS SQL 2014 + Analysis Services + MS BI 2013

Задача: развернуть примитивный OLAP куб, данные дергать напрямую из SQL базы(полная копия РИБ боевой базы)

Проблема: добавление нового измерения(справочник номенклатура), выбор ключевого поля "_IDRRef"(тип: Binary) --> ошибка
"DimensionAttribute [Reference154].[IDR Ref] : The 'Binary' data type is not allowed for the 'KeyColumns' property"

Вопросы:
1.1 Указать ключевым полем измерения - поле справочника "_IDRRef"(где храниться ссылка) - невозможно т.к. "_IDRRef" имеет тип "Binary" ?  
1.2 Напрямую тащить данные из базы не получиться - придется делать промежуточную sql базу (в т.ч. для того чтобы _IDRRef сконвертировать в другой тип) ?
2. Иерархия с parent-child будет сильно тормозить - сразу от нее отказываться ? Объемы данных достаточно большие.

(0) Не дергай напрямую из базы. Настойчиво рекомендую.

(1) Аргументы

(2) Для начала лицензионное соглашение:
"Лицензиат обязуется не допускать нарушений исключительных прав Правообладателя на ПРОГРАММНЫЙ ПРОДУКТ, в частности, не совершать и не допускать совершения третьими лицами следующих действий без специального письменного разрешения Правообладателя: ... осуществлять доступ к информационной базе ПРОГРАММНОГО ПРОДУКТА и построение систем на основе ПРОГРАММНОГО ПРОДУКТА с помощью средств и технологических решений, не предусмотренных в сопроводительной документации;"

2ой аргумент: тк. ты собираешся по любой делать промежуточную базу - так и пиши в нее средствами 1С сразу.
3ий аргумент: опыт. сталкивался с этой задачей несколько раз у разных заказчиков. минимум геморроя - выгрузка данных средствами 1С.

(3)
2. Уже есть боевая база и ее копия РИБ для тяжелых расчетов.
3. Выгрузка куда ?

(4) Куда угодно. Можешь напрямую в SQL. Хочешь - предварительно куда-нибудь в файл для контроля и доп.обработки.

(5) Ну а в чем аргументация. Какие были проблемы при работе напрямую с базой ?

(6)
1. Простота поддержки.
2. Простота организации достаточно сложных источников данных. Например с использованием планов обмена.
3. Возможность доп.обработки на этапе выгрузки

(7)
1. Неясно в чем простота и сложность
2. Планы обмена не нужны. Все легко дергается из SQL базы 1С.
3. Нет необходимости.

(8) Представь, что ты уволишься, и к твоему работодателю придет мальчик из франча с опытом работы полгода+3 месяца развоза ИТС. И надо слегка изменить источники, скажем, в связи с  переименованием полей. Мальчик относительно легко сделает это на 1С и не сделает вообще используя другие средства, тк он их не знает и знать не хочет.

В любом раскладе - решать тебе.

(0) Имхо  курс правильный .   Думаю покопаться  - все взлетит. Исключение - чтобы  не уехали название полей в скуле .

Касаемо "торможений " парент и прочее...  встроенные индексы .

(10) раскопал про конветацию http://www.sql.ru/forum/916453/olap-mssql-1s8-svyaz-mer-i-izmereniy

Не уехали названия полей - а разве могут ?

(12) Ну.... да . Если типовая и обновления ... уедут .   Если какая нить статика .. и обновление из храна -   не уедут .

Что еще ... утановлено ... штааа при работе с боевой (запросы напрямую из рабочей  в момент работы) - могут задваиваться  id refы. Получается что работать лучше с копией .

Еще по полям .. если поле было односсылочным - стало мульти . Название разлетится однозначно.