Pull to refresh

Comments 11

Почему бы не взять через COM все данные?
Это если разово; а если инкрементно, то обмен данными. Все в XML, чисто и красиво.
Вот это культурные способы, а не обработкой в csv.
>Почему бы не взять через COM все данные?
Потому, что тормознуто. Сделайте тест на нескольких десятках миллионов записей, и убедитесь сами.
Код приведен выше. Как видно
           foreach (dynamic catalog in a1CConn.Metadata.Enums)
            {
                string enumName = catalog.Name;
                dynamic query = a1CConn.NewObject("Query");
                query.Text = "select * from enum." + enumName;
                dynamic items = query.Execute().Unload();

....
(не буду сюда его еще раз вставлять)

Вы по-моему уже не на мой вопрос отвечаете. Я спрашиваю про все остальные данные.
Если вы имели в виду «как мы брали данные фактов и измерений», то ответ: в этом проекте — писали прямые SQL запросы. Как писали — см. статью: показаны конкретные обработки, которые помогають написать эти запросы.

Единственная проблема была в том, что вытянуть названия элементов перечислений с помощью SQL запроса — невозможно. Это единственная штуковина, которую приходилось извлекать с помощью COM. Но это извлечение происходит 20 секунд где-то (по всем перечислениям). Согласитесь, в ETL процедуре не самое тяжелое место.

А так в большинстве проектов прямыми SQL запросами данные стараемся не вытягивать. Мы в основном делаем так: заказчик своими силами пишет обработку, которая выдает нам данные в промежуточную «буферную базу» (это может быть либо csv файлы, либо таблицы в sql server, либо dbf — что угодно), а мы тянем нашим UniveralETL или SSIS пакетом из этой буферной базы. Такой подход гарантирует корректность данных и распределение ответственности: программист 1С заказчика отвечает за правильность своих обработок, мы — за все, что дальше после буферной БД.
Но это уже другая тема.
С выходом 8.3.5 все будет проще. 1С наконец сделали REST-интерфейс к базе, причём он генерируется автоматом.
Да и в 8.1 не тяжело было сделать SOAP сервис, отдающий нужные данные.
А для «нормальных» значений перечислений можно использовать псевдофункцию ПреставлениеСсылки() прямо в запросах 1с. Ну, или XMLЗначение(ПеречислениеСсылка)
а почему бы вам здесь не написать статью с детальным объяснением как это делается? думаю не я бы один был бы благодарен. мы тоже были бы рады от других поучиться.
Чтобы исключить субъективные ощущения, в статье не хватает замеров времени выгрузки на Ваших данных:
1) Через обработку 1С
2) COM-соединение к 1С (например, на C#)
3) запрос к базе SQL + COM-соединение к 1С для получения значений перечислений (предложенный вариант)
И самый важный вопрос – нашелся ли 1С-программист и где он был все это время?
Если мы BI проект (в котором самая тяжелая часть — это ETL) уже сделали через прямые SQL запросы, то Вы уж простите — но не будем делать то же самое второй раз через обработки 1С или через COM только для того, чтобы замерить время. Так что я не смогу здесь удовлетворить Ваш запрос.

Но могу уверить вас в том, что если будете тянуть данные (я не о перечислениях, а о регистрах, документах и т.д.) через COM или через обработку 1С — то будет существенно медленее, чем потянуть SQL запросом.

Тут проблема в том, что вытянуть перечисление прямым запросом — невозможно. Вот собственно это единственная часть, которая тянется через COM, все остальное — через SQL.

>«И самый важный вопрос – нашелся ли 1С-программист и где он был все это время? „

Конкретно в этом проекте была ситуация, что программист 1с заказчика уволился, на его место взяли нового, на которого свалилась сразу куча задач, и времени делать обработки у него никак не было.

Заказчик тем не менее BI хотел. Поэтому мы сошлись на том, что тянем SQL запросами напрямую, а он соглашается с тем, что это все может в один момен вылететь (если вдруг поменяется конфигурация 1С), и соглашается с возможными ошибками в выборках данных.

Но еще раз: не рекомендую BI разработчикам так делать. лучше если 1С програмист у заказчика будет сам выдавать данные в промежуточную бд.
Only those users with full accounts are able to leave comments. Log in, please.