Comments 16
В целом, решение рабочее, главное чтобы базу сильно не реструктуризировали :) Если с обычными типами все довольно просто, и их служебные имена в пределах базы не должны изменяться, то поля составных типов имеют не столь очевидную структуру, т.е. при расширении какого-то ссылочного поля до составного его структура может заметно измениться и запросы придется изменять. Красивого решения по автоматической генерации таких запросов я пока не встречал, правда не уверен, что в нем вообще есть такая уж необходимость. Хотя, когда поддерживаешь несколько предприятий с идентичной конфигурацией, имена хранения у них все равно будут отличаться — в таком случае было бы неплохо автоматизировать эти преобразования.
Здесь в конце статьи - про использованные обработки. https://infostart.ru/1c/articles/1639249/
А разве прямые SQL запросы к базе 1с не являются нарушением лицензии 1с? Несколько лет назад изучал этот вопрос, и встречался пункт о запрете.
Согласен тем более на 8.3 появилось довольно много других возможностей для синхронизаций(web серверы, oData и.т.д.)
Сталкивался с PowerBI, пробовал данные о продажах передавать через OData, но это нереально по времени. В итоге остановились на варианте регламентной выгрузки данных обработкой раз в сутки во внешнюю базу на SQL за несколько последних месяцев, либо по требованию. Зато получился довольно гибкий инструмент, позволяющий сразу запросами внутри 1С сформировать необходимые данные в том виде, в котором они требуются для PowerBI. Минус — задержка в данных в течение дня, но это некритично в моем случае, можно было бы и чаще запускать выгрузку.
Лицензионное соглашение это важный закон, его нарушать нельзя. Вот ссылка на него https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/?
Соглашение не запрещает, например, сделать вторую копии базы 1С на СУБД (отрубить её от 1С Сервера, база теперь только на СУБД и к 1С не имеет отношения, работоспособность не нарушает), и с неё считывать данные. Материя тонкая согласен в ней надо понимать и быть осторожным.
Прикрепленные файлы:
Ну и если есть отдельная копия, то можно сделать прокси-базу с подготовленными view-хами, в которых уже использовать понятные имена, и управлять мэппингом полей на уровне СУБД. Кроме того можно «расшивать» всякие непонятности типа полей составного типа.
Согласен с @yukon39
Делаем RO асинхронную реплику (вам же не нужно прям в realtime получать данные, 100-1000 мс задержки вполне норм, при этом не нагружаем прод. базу ожиданиями фиксации транзакций в RO реплике).
В реплике на основании информации о соответствии полей таблиц и объектов метаданных в той же базе генерируем View с названиями таблиц и полей соответствующими именам метаданных.
В итоге имеем отдельный сервер где можно крутить разные аналитики и SQL интеграции не нагружая основной сервер. При этом запросы пишутся почти как в 1С Конечно итоги и срезы последних нужно самим подключать, и какой то навык нужно иметь, лучше конечно первый раз писать в консоли и потом транслировать в SQL и затем уже писать через View что бы меньше ошибок. Основные плюсы потом в сопровождении, проще читать, проще менять запросы и.т.п.
Переход с 1С: УПП на 1C:ERP: Переделываем интеграции с SQL-запросами к СУБД (на примере УПП — QlikView — ERP)