Комментарии 17
Как вариант (если «Нарушает лицензионное соглашение с 1С» не останавливает) можно сгенерировать View с нормальными (Бизнес-смысл в наименованиях) именами таблиц.
Есть готовые инструменты:
https://infostart.ru/public/352750/ (Первая кнопка).
https://infostart.ru/public/394013/
Эти view так же нужно будет постоянно обновлять при изменении конфигурации, но зато не требуется доп. регистр.
Для новых версий 8.3.9 и выше более правильно будет разработать расширение (плагин) которое будет содержать в себе WEB или HTTP сервис к которому будет обращаться внешня система для получения данных. И в нем будет логика получения изменных данных.
Общение через формализованный интерфейс всегда лучше чем просто лазить в чужую базу данных. Именно поэтому 1С запрещает обращаться к SQL напрямую.
Тем более что 1С это не только SQL но и Oracle, Postgresql, DB2, собственная файловая СУБД.
Есть готовые инструменты:
https://infostart.ru/public/352750/ (Первая кнопка).
https://infostart.ru/public/394013/
Эти view так же нужно будет постоянно обновлять при изменении конфигурации, но зато не требуется доп. регистр.
Для новых версий 8.3.9 и выше более правильно будет разработать расширение (плагин) которое будет содержать в себе WEB или HTTP сервис к которому будет обращаться внешня система для получения данных. И в нем будет логика получения изменных данных.
Общение через формализованный интерфейс всегда лучше чем просто лазить в чужую базу данных. Именно поэтому 1С запрещает обращаться к SQL напрямую.
Тем более что 1С это не только SQL но и Oracle, Postgresql, DB2, собственная файловая СУБД.
Не очень понимаю, почему использование View не нарушает лицензионное соглашение?
Предложенные средства работают, но решают немного другую задачу. Наша задача — получение измененных данных из 1С. Статья в первую очередь о правильном заборе данных из 1С средствами СУБД.
Спасибо за комментарий)
Предложенные средства работают, но решают немного другую задачу. Наша задача — получение измененных данных из 1С. Статья в первую очередь о правильном заборе данных из 1С средствами СУБД.
Тем более что 1С это не только SQL но и Oracle, Postgresql, DB2.Разумеется. И в любой из этих СУБД, кроме файловой, предложенные методы работают.
Спасибо за комментарий)
Не очень понимаю, почему использование View не нарушает лицензионное соглашение?
Нарушает, я об этом и написал.
(если «Нарушает лицензионное соглашение с 1С» не останавливает)
Вариант с генерацией View решает задачу забора данных из СУБД.
В этом случае SQL запросы выглядят как то так:
select
[Дата_Time]
,[Ссылка]
,1
,0x01
,[Контрагент]
,[Состояние]
,0x00
,[ДатаИзмененияСостояния]
,[УчетныйМесяц]
from [dbname].[dbo].[Документ_ИзменениеСостоянияКонтрагента]
т.е. все то же самое что у вас в статье только вместо того что бы создавать регистр, обработка генерирует (И выполняет) SQL скрипт создания VIEW, примерно такой:
/****** View для таблицы:Справочник.СохраненныеНастройки.Пользователи ******/
USE []
GO
IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[Справочник_СохраненныеНастройки_Пользователи]'))
DROP VIEW [dbo].[Справочник_СохраненныеНастройки_Пользователи]
GO
CREATE VIEW [dbo].[Справочник_СохраненныеНастройки_Пользователи]
AS
SELECT
_LineNo535 AS НомерСтроки,
_Fld536_TYPE AS Пользователь_TYPE,
_Fld536_RTRef AS Пользователь_RTRef,
_Fld536_RRRef AS Пользователь,
_Fld537 AS ПравоИзменения,
_Reference54_IDRRef AS Ссылка,
_KeyField AS _KeyField
FROM dbo._Reference54_VT534
GO
И так для каждого объекта метаданных. В итоге все объекты (включая и таблицы регистрации изменений) доступны как View с понятными именами, и к ним можно делать запросы.
Моя статья не о том, как сгенерировать View, которые будут смотреть в базу.
Когда есть задача забрать данные, и сделать это достаточно оптимально, не вытягивая таблицы целиком, можно воспользоваться версиями объектов или планами обмена.
И эту задачу указанные генераторы не решают. И, конечно, это можно завернуть в еще одну удобную обертку в виде View.
Когда есть задача забрать данные, и сделать это достаточно оптимально, не вытягивая таблицы целиком, можно воспользоваться версиями объектов или планами обмена.
И эту задачу указанные генераторы не решают. И, конечно, это можно завернуть в еще одну удобную обертку в виде View.
А еще есть odata, причем по всем стандартам, и эксель и павер би с ней отлично работают.
Так что если цель стоит «забирать» максимально «правильно», то или одата, или внешние источники.
Вы куда то не туда пошли копать, если надо забирать изменения — то только через саму 1С, когда она пишет данные в нужную вам на скуле таблицу.
Так что если цель стоит «забирать» максимально «правильно», то или одата, или внешние источники.
Вы куда то не туда пошли копать, если надо забирать изменения — то только через саму 1С, когда она пишет данные в нужную вам на скуле таблицу.
Есть вариант использовать внешние источники. Тогда больше логики придется реализовать 1С + автоматизация процесса выгрузки средствами 1С. Согласен, что имеет право на существование, как подход. Но я бы не сказал, что он единственно верный из возможных. Из минусов — мы опять же не можем использовать версии объектов, только планы обмена и онлайновая запись, что получается дороже. И хуже контроль над процессом со стороны ETL.
Версии объектов появятся в 8.3.11, плюс есть SQL версионники, если вам нужны версии — используйте их.
На счет того, что хуже контроль со стороны ETL — поспорю.
1С намного проще определить — менялось что-то ключевое или нет. А саму выгрузку можно делать регламентом.
Так что тут очень много НО.
Все зависит от задачи. Какую цель преследуете именно вы?
На счет того, что хуже контроль со стороны ETL — поспорю.
1С намного проще определить — менялось что-то ключевое или нет. А саму выгрузку можно делать регламентом.
Так что тут очень много НО.
Все зависит от задачи. Какую цель преследуете именно вы?
Опять же все довольно просто и очевидно, несмотря на русский язык.— может, благодаря русскому языку?
Самое главное не написали:
Реализация «высокоуровневого» интерфейса
- После обновления конфигурации 1С или внесения в нее доработок или внесения доработок в ETL изменения в формат высокоуровневой выгрузки требуется внести только в случае, когда: были изменены синхронизируемые таблицы, при этом если изменения такие, что их можно привести к формату пакета обмена (DTO), то изменения вносятся только на той стороне, в которой они были внесены. Изменение самого формата DTO требуется в крайне редких случаях.
От чего прозрачная поддержка и адаптируемость к новым требованиям на будущее.
Реализация на СУБД
- После внесения любого изменения в 1С, даже не сильно связанного с вашим обменом, а так же при простых операциях, как реиндексация или реструктуризация данных, что в 1С доступно вообще из административного режима, может формат хранения данных в СУБД измениться. В первую очередь 1С запрещает обращаться к таблицам СУБД как раз из-за того, что это может нарушить работу самого 1С. Если чтение данных — это еще допустимо (образно), то запись непосредственно в базу — полный отказ от гарантий. Соответственно использование данного подхода — постоянный риск привести в неработоспособное состояние обмен с ETL и как следствие постоянные часы внеплановых доработок обмена.
Вопрос с же с производительностью всегда является спорным, при оптимизации запросов чтения и формирования DTO пакетов, определения оптимального размера самого пакета данных, выбором периодичности сообщений обмена, можно даже на медленном сервере с большой базой данных добиться хорошей производительности.
На самом деле, вся проблема в том, что Вы предлагаете использовать ПолучитьСтруктуруХраненияБазыДанных не по назначению. Полагаться на результат работы данного метода для разработки непосредственных обращений — неправильное решение.
Данный метод существует непосредственно для самих 1Сников. Можно подумать, "Зачем 1Сникам знать низкоуровневую структуру базы данных, если вы все работаете с объектной моделью?". Так вот, он и сделан для того, что бы 1Сники не задумывались об этой низкоуровневой структуре. Так зачем же он нужен?
Запросы в 1С — тоже объектно ориентированные, и работают с типизированными данными, фактически это значит, что по значению колонки, если знать какой тип объекта в ней хранится, можно получить данные вложенного объекта по ссылке, при этом будет неявно выполнено соединение с таблицей, хранящей вложенный объект.
Само собой такие запросы просто так на СУБД не выполняются, предварительно они транспонируются в такой запрос, который понимает СУБД. Но проблема в том, что каждая СУБД может по своему понимать один и тот же запрос 1С. Да еще и перед выполнение запроса СУБД строит план выполнения запроса, который рассчитывается динамически от состава запрашиваемых данных, текущего объема таблиц, и еще множества разных факторов (составы индексов, кластерный индекс, знание о количестве выбираемых строк и.т.д.). Как следствие в некоторых случаях планы выполнения запроса к реляционным таблицам могут быть не оптимальны.
1С позволяет записывать в технологический журнал информацию о том, для какого запроса какой план выполнения был получен у СУБД, а этот план строится самой СУБД и в нем фигурируют именно имена таблиц самой СУБД. Вот для восстановления реальных имен объектов 1С для анализа запросов и их оптимизации и есть метод ПолучитьСтруктуруХраненияБазыДанных.
- Написали и выполнили запрос
- Получили журнал регистрации
- Восстановили реальные имена объектов
- Построили граф выполнения плана запроса
- Выполнили оптимизацию запроса
Примерно так это все выглядит. Специальные инструменты разработчика, как та же "Консоль запросов", запускаемая в режиме 1С: Предприятие и входящая в состав поставки Библиотеки Стандартных Подсистем, является примером.
Чем не угодили HTTP-сервисы в 1С?
Начиная с 8.2 на стороне 1С можно разрабатывать XDTO-сервисы которые смогут отдавать вам все что захотите.
Отличная статья «как не надо делать» Если не знаешь 1С можно же позвать тех, кто знает, а не создавать еще одно порожденте кровавого энтерпрайза
Такая хрень была еще оправдана с 7.7 поскольку вариантов особо не было… Но! Не нужно делать это с 8.2 и старше! Как сказано выше — сервисы ваше всё. А так — любое изменение структуры базы в конфигураторе приведет к переписыванию подобного кода.
Согласен с коллегами, которые отписались выше. У вас изначально были неправильные предпосылка и потому вы пошли не тем путем.
То, что вы описали как четыре минуса для получения данных с помощью стандартных средств 1С (SOAP, OData или HTTP-сервисы с XML/JSON), вообще к ним не относятся.
Расписания выгрузок/загрузок и прочая «роботизация» находится на вашей стороне, а 1С при таком подходе выступает как сервер данных: вы сделали запроса и получили ответ. Формально это даже не минус, а просто реалии вашей работы как «ETL-специалиста» с любым источником данных.
Что же это за особенности? У меня уже есть ряд мобильных разработок для удаленной работы с базами 1С и они работают довольно шустро даже в сценариях, когда требуется полная и актуальная НСИ. В первом варианте происходит быстрая выборка, сериализация в нужный формат и возврат веб-сервером. Во втором варианте перед запросом нужно каждый раз актуализировать информацию по меппингу и только затем уже можно выбирать данные и преобразовывать в тот вид, с которым вы будете далее работать.
В первом подходе никаких изменений вносить не требуется, а при непосредственном доступе к СУБД из-за изменения структуры и названия таблиц эти изменения постоянны.
Тут даже комментировать особо нечего. Весь контроль целостности находится на стороне платформы, которая гарантирует в 99,9% случаев успешные чтение и запись (еще есть редкие случаи сбоев самой СУБД на которые 1С влиять не может). А вот бездумный INSERT/UPDATE/DELETE напрямую в СУБД может натворить делов… Но вы же в статье только про получение информации говорите? Тогда какая к черту целостность? Скорее тут вопрос в согласованности данных! В режиме 1С вы получаете гарантированно цельный и согласованный объект, а в режиме СУБД можете напутать с версиями и JOIN-ми табличных частей. Не говоря уже о том, что легко нарваться на грязное чтение.
Для захвата данных из 1С у вас есть 2 пути:
То, что вы описали как четыре минуса для получения данных с помощью стандартных средств 1С (SOAP, OData или HTTP-сервисы с XML/JSON), вообще к ним не относятся.
Появляется еще один источник для ошибок в виде дополнительных выгрузок-загрузок,
расписаний, роботизации
Расписания выгрузок/загрузок и прочая «роботизация» находится на вашей стороне, а 1С при таком подходе выступает как сервер данных: вы сделали запроса и получили ответ. Формально это даже не минус, а просто реалии вашей работы как «ETL-специалиста» с любым источником данных.
Это будет работать существенно медленнее из-за особенностей интерфейсов 1С
Что же это за особенности? У меня уже есть ряд мобильных разработок для удаленной работы с базами 1С и они работают довольно шустро даже в сценариях, когда требуется полная и актуальная НСИ. В первом варианте происходит быстрая выборка, сериализация в нужный формат и возврат веб-сервером. Во втором варианте перед запросом нужно каждый раз актуализировать информацию по меппингу и только затем уже можно выбирать данные и преобразовывать в тот вид, с которым вы будете далее работать.
При любых изменениях в захватываемых данных, вам придется вносить изменения в выгрузки
В первом подходе никаких изменений вносить не требуется, а при непосредственном доступе к СУБД из-за изменения структуры и названия таблиц эти изменения постоянны.
Это вызовет больше ошибок в целостности данных, чем работа напрямую с СУБД
Тут даже комментировать особо нечего. Весь контроль целостности находится на стороне платформы, которая гарантирует в 99,9% случаев успешные чтение и запись (еще есть редкие случаи сбоев самой СУБД на которые 1С влиять не может). А вот бездумный INSERT/UPDATE/DELETE напрямую в СУБД может натворить делов… Но вы же в статье только про получение информации говорите? Тогда какая к черту целостность? Скорее тут вопрос в согласованности данных! В режиме 1С вы получаете гарантированно цельный и согласованный объект, а в режиме СУБД можете напутать с версиями и JOIN-ми табличных частей. Не говоря уже о том, что легко нарваться на грязное чтение.
Еще один комментарий, но уже без цитат.
1) Вы предлагаете снимать программу с поддержки и писать данные по конфигурации напрямую в конфигурацию. Для Бухгалтерий, которые регулярно самостоятельно обновляются без участия «программиста» — это не выход из-за поломки такого автообновления и вам выше правильно напомнили про возможность создать сервис с помощью расширения, который будет выдавать нужную информацию.
2) И еще вы совершенно верно указали, что названия таблиц при реструктуризации изменяются. Так от куда у вас взялась идея, что ваша таблица с метаданными ВСЕГДА будет называться _InfoReg27083? Ее название тоже может легко изменится при обновлении, когда изменится состав дерева метаданных (или при переходе на новую версию платформы). Т.е. вместо того, что бы просто брать готовые данные, вы сами себя обрекаете на перепроверку и возможное переписывание ваших скриптов для каждой из попыток загрузки.
*) И сколько можно про русский язык? Если вы не знаете русского языка, то пишите код на английском. Есть целые линейки программ из серии «1С: Предприятие», которые ориентированы на внешний рынок и написаны полностью на английском языке без единого русского слова (есть даже две типовые конфигурации, которые пишет сама компания 1С, а не ее партнеры — Small Business и Accounting Suite). Вот только на русскоязычной территории СНГ и ближнего зарубежья (Прибалтика, Молдова и пр.) предпочитают именно русский язык и это является конкурентным преимуществом при распространении.
1) Вы предлагаете снимать программу с поддержки и писать данные по конфигурации напрямую в конфигурацию. Для Бухгалтерий, которые регулярно самостоятельно обновляются без участия «программиста» — это не выход из-за поломки такого автообновления и вам выше правильно напомнили про возможность создать сервис с помощью расширения, который будет выдавать нужную информацию.
2) И еще вы совершенно верно указали, что названия таблиц при реструктуризации изменяются. Так от куда у вас взялась идея, что ваша таблица с метаданными ВСЕГДА будет называться _InfoReg27083? Ее название тоже может легко изменится при обновлении, когда изменится состав дерева метаданных (или при переходе на новую версию платформы). Т.е. вместо того, что бы просто брать готовые данные, вы сами себя обрекаете на перепроверку и возможное переписывание ваших скриптов для каждой из попыток загрузки.
*) И сколько можно про русский язык? Если вы не знаете русского языка, то пишите код на английском. Есть целые линейки программ из серии «1С: Предприятие», которые ориентированы на внешний рынок и написаны полностью на английском языке без единого русского слова (есть даже две типовые конфигурации, которые пишет сама компания 1С, а не ее партнеры — Small Business и Accounting Suite). Вот только на русскоязычной территории СНГ и ближнего зарубежья (Прибалтика, Молдова и пр.) предпочитают именно русский язык и это является конкурентным преимуществом при распространении.
В общем, согласен почти со всеми комментариями, кроме некоторых моментов. Например — по поводу грязного чтения. Сама 1С использует read uncommited в полный рост).
И еще один важный момент — реальная практика показывает, что это работает. Работает стабильно. Годами. Со всеми версиями, начиная от 8.1.
И еще один важный момент — реальная практика показывает, что это работает. Работает стабильно. Годами. Со всеми версиями, начиная от 8.1.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
1C и ETL