Comments 11
Почему бы не взять через COM все данные?
Это если разово; а если инкрементно, то обмен данными. Все в XML, чисто и красиво.
Вот это культурные способы, а не обработкой в csv.
Это если разово; а если инкрементно, то обмен данными. Все в XML, чисто и красиво.
Вот это культурные способы, а не обработкой в csv.
>Почему бы не взять через COM все данные?
Потому, что тормознуто. Сделайте тест на нескольких десятках миллионов записей, и убедитесь сами.
Потому, что тормознуто. Сделайте тест на нескольких десятках миллионов записей, и убедитесь сами.
Потому, что тормознуто
А вы в 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С заказчика отвечает за правильность своих обработок, мы — за все, что дальше после буферной БД.
Но это уже другая тема.
Единственная проблема была в том, что вытянуть названия элементов перечислений с помощью SQL запроса — невозможно. Это единственная штуковина, которую приходилось извлекать с помощью COM. Но это извлечение происходит 20 секунд где-то (по всем перечислениям). Согласитесь, в ETL процедуре не самое тяжелое место.
А так в большинстве проектов прямыми SQL запросами данные стараемся не вытягивать. Мы в основном делаем так: заказчик своими силами пишет обработку, которая выдает нам данные в промежуточную «буферную базу» (это может быть либо csv файлы, либо таблицы в sql server, либо dbf — что угодно), а мы тянем нашим UniveralETL или SSIS пакетом из этой буферной базы. Такой подход гарантирует корректность данных и распределение ответственности: программист 1С заказчика отвечает за правильность своих обработок, мы — за все, что дальше после буферной БД.
Но это уже другая тема.
С выходом 8.3.5 все будет проще. 1С наконец сделали REST-интерфейс к базе, причём он генерируется автоматом.
Чтобы исключить субъективные ощущения, в статье не хватает замеров времени выгрузки на Ваших данных:
1) Через обработку 1С
2) COM-соединение к 1С (например, на C#)
3) запрос к базе SQL + COM-соединение к 1С для получения значений перечислений (предложенный вариант)
И самый важный вопрос – нашелся ли 1С-программист и где он был все это время?
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С програмист у заказчика будет сам выдавать данные в промежуточную бд.
Но могу уверить вас в том, что если будете тянуть данные (я не о перечислениях, а о регистрах, документах и т.д.) через COM или через обработку 1С — то будет существенно медленее, чем потянуть SQL запросом.
Тут проблема в том, что вытянуть перечисление прямым запросом — невозможно. Вот собственно это единственная часть, которая тянется через COM, все остальное — через SQL.
>«И самый важный вопрос – нашелся ли 1С-программист и где он был все это время? „
Конкретно в этом проекте была ситуация, что программист 1с заказчика уволился, на его место взяли нового, на которого свалилась сразу куча задач, и времени делать обработки у него никак не было.
Заказчик тем не менее BI хотел. Поэтому мы сошлись на том, что тянем SQL запросами напрямую, а он соглашается с тем, что это все может в один момен вылететь (если вдруг поменяется конфигурация 1С), и соглашается с возможными ошибками в выборках данных.
Но еще раз: не рекомендую BI разработчикам так делать. лучше если 1С програмист у заказчика будет сам выдавать данные в промежуточную бд.
Sign up to leave a comment.
Извлечение данных из БД 1С: проблемы с перечислениями