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