Можно не разбираться, а взять готовое.
www.ivn.newmail.ru

Насчет треннинга лучше в мыло ivanov-soft@inbox.ru

К слову, Mad Maxx. Если можно поясни вот какие моменты.
Обычно для построения OLAP-отчетности для 1С достаточно сделать 2-5 относительно сложных view на регистры и проводки, и примерно 10-20 фактически одинаковых view на справочники.
Написать view на справочники из 2х строк не сможет только полный идиот.
Сделать view вынимающие фактом можно в готовом виде только для стандартных конфигураций, но для этого "генератор" не нужен. У клиентов в нише "1С + SQL" обычно несколько разных баз и в разной структуре, плюс свои заморочки. Поэтому приходится делать довольно сложный SQL-запрос для вытягивания данных. Сгенерировать его автоматом для реальных систем фактически невозможно. Еще более сложно сопровождать такой генерированный запрос. Если это view, то даже в самых сложных случаях можно проблему победить через SQL-запрос.
Например, мой клиент производящий "Помарин" и прочую косметику (АленМак) столкнулся с проблемой разной структуры номенклатуры в своих конфигурациях. 1 час отладки и удалось склеить номенклатуры с разными деревьями.
Делать хранилища для такой простой системы как 1С, на мой взгляд в большинстве случае неправдано. Только тормоза добавляет.
На мой взгляд, генератор SQL-запросов может быть полезен корп. разработчикам, которые не состоянии сделать простейший select ... from и не желают повышать свою квалификацию в SQL.
Но много ли таких? Мне кажется нет, корп. разработчики не идиоты, в это я точно верю.

Я говорил именно про большиство случаев.
Примерно в 30% я делаю для 1С DWH. Это нужно в том случае, если данные можно собрать в несколько проходов.
Процессинг через DWH сильно уступает по скорости view.
Во-первых, MS SQL обязан закомитить данную большую транзакцию. Это не быстро. Можно конечно, применить bulk insert, он работает на 20% быстрее. Но в задачах, которые мы обсуждаем частно нужно делать update DWH.
Во-вторых, если повесить много индексов на DWH время его создания еще больше упадет, т.к. индексы MS SQL надо перестраивать.

Для примера тесты из жизни. view с union для откачки данных из 2х конфигураций. Выполнение запроса на процессинге - 20 сек.
Тоже самое через DWH, запрос идет 12 сек, но подготовка DWH занимает 50 сек.

В принципе я считаю, раз начал возится с DWH стоит сразу сделать инкрементальную подкачку. Вот это действительно убыстрение и десятки, если не в сотни раз.
Но Mad Maxx этого не предлагает...

DWH всегда строится медленней, чем аналогичный линейный запрос, т.к. результаты надо записывать на диск и не просто записывать, а через лог.
Потом, до 100 тыс. записей MS SQL фактически не нуждается в индексах. Очень быстро работает система виртуальных hash-индексов. Посмотрите Query Plan.
С блокировками замечание верное, но режимы изоляции транзакций на то в MS SQL и есть. Хотя бы банальный nolock. Если не использовать накопительные регистры 1С, можно читать в d. read и фантомы не появятся.

Единственная глобальная проблема со view, это то, что оптимайзер MS SQL теряет контекст обращения к primary key связанных таблиц в случае использования union. Это обходимо, но нужен опыт.

Вообще говоря. При типичном звездо-подобном запросе MS SQL нужны только primary key, они в 1С есть. Использование FK дает выгоду только на фильтрации, т.е. в случае использования Drill Though. Вот это действительно аргумент в пользу DWH.

Давайте я резюмирую и закончу это обсуждение.
Базы 1С крохотные для MS SQL это надо понять и не заниматься оптимизацией на пустом месте. 1С это даже не Axapta.
Штатная оптимизация SQL-запросов под view обычно решает все проблемы. Иногда DWH полезен, но в стандартных конфигурациях 1С он не нужен. Если введен DWH, нужно запускать инкр. подкачку и Drill Through.