Вход | Регистрация

  1  2
1С:Предприятие :: 1С:Предприятие 8 общая

Минусы прямых запросов к 1С8

Минусы прямых запросов к  1С8
Я
   zavyzka
 
22.10.18 - 16:20
У клиентов периодически возникает потребность забирать данные из 1С в какую-то другую внешнюю систему (OLAP и т. д.). Рзаработчики внешних систем всегда предлагают забирать на прямую из ms sql. Я обычно говорю, что это плохое решение и лучше подключаться к 1С, а не к ms sql. Но исчерпывающих доводов, почему плохо забирать из sql предоставить не могу. Просьба поделиться мыслями на эту тему.
 
 
   vitkhv
 
101 - 23.10.18 - 09:25
(100) Да, автоматом по ночам.
   vitkhv
 
102 - 23.10.18 - 09:29
(100) Из моей обработки, по созданию VIEW.

        
    ТекстПредставления="
        |DROP VIEW  IF EXISTS "+ИмяПредставления+"
        |go
        |
        |CREATE VIEW "+ИмяПредставления+"
        | AS 
        |SELECT ";
Для Каждого КолонкиБД ИЗ  СтрокаБД.Поля Цикл
..............
КонецЦикла
   Aleksey
 
103 - 23.10.18 - 09:32
(93) Ну хорошо бухгалтер принес обработку - "расширение".
Я знаю единственный способ добавить расширение - это через предприятие. Через конфигуратор у меня не получается добавить расширение. Научите.
   Aleksey
 
104 - 23.10.18 - 09:33
(95) обработка в виде расширения
   vitkhv
 
105 - 23.10.18 - 09:33
(100) Единственное для перечеслений я создаю отдельную таблицу и функцию dbo.ЗНАЧЕНИЕ. И в тексте запроса можно писать так:

WHERE Номенклатура.СтавкаНДС = dbo.ЗНАЧЕНИЕ('Перечисление.СтавкиНДС.НДС18')
   dmpl
 
106 - 23.10.18 - 09:41
(102) И эту обработку написать быстрее, чем сервис?
   vitkhv
 
107 - 23.10.18 - 09:42
(106) Почему нет?
   Cyberhawk
 
108 - 23.10.18 - 09:43
(103) "Через конфигуратор у меня не получается добавить расширение. Научите" // Там неочевидное приходится совершать - добавить новое расширение, а потом загрузить его конфигурацию из файла
   vitkhv
 
109 - 23.10.18 - 09:43
(106) По крайней мере я напишу ее точно быстрее чем сервис.
   dmpl
 
110 - 23.10.18 - 09:44
(109) Сейчас-то да, а в первый раз?
 
 Рекламное место пустует
   vitkhv
 
111 - 23.10.18 - 09:44
(104) Я все расширения через конфигуратор добавляю, в чем проблема?
   vitkhv
 
112 - 23.10.18 - 09:45
(110) В первый раз я свой парсер запросов написал. ))))
   Cyberhawk
 
113 - 23.10.18 - 09:46
(111) Не создать, а подключить уже созданный файл *.cfe
   vitkhv
 
114 - 23.10.18 - 09:46
(110) ТК в 2000 сервере нельзя было инсертить виев я про них забыл.
   vitkhv
 
115 - 23.10.18 - 09:48
(113) через конфигуратор я расширения CFE подключаю. В чем проблема? Те же инструметы разработчика.
   vitkhv
 
116 - 23.10.18 - 09:53
(113) Я честно говоря даже незнаю как их через предприятие подключать.
   ADirks
 
117 - 23.10.18 - 09:54
(106) Думаю что быстрее. Более того, написать такую обработку надо всего один раз, дальше оно само. И руками её запускать не нужно. Делается механизм, отслеживающий изменения конфигурации, и запускающий генерацию всего что нужно. Т.е. один раз сделали, и забыли навсегда.
   gantonio
 
118 - 23.10.18 - 10:02
вот где 1с , а гда олап ? Знаете, что в обработке данных для всяких статистических задач, как бы считается , что 60-80 процентов времени уходит на подготовку данных. Т.е. модель ищется серди мусора, данные чистятся ,находятся нужные.
А вы собираетесь реквизитик добавить , да и вообще сделать какую то проекцию в модель о которой вы ничего не понимаете. да с вами просто никто не хочет общаться на тему высоких материй.
   Сияющий в темноте
 
119 - 23.10.18 - 10:30
Кстати,когда в какой то таблице в имя поля добавляется удалить,а новые поля не создаются,то таблица в Sql никак не меняется,и никто не узнает,что данных там уже нет.
Если анализ данных требует с ними выполнять множество преобразований,то все равно это будет делаться в отдельной базе,так что со стороны 1с можно написать план обмена,чтобы новую базу заполнять данными,причем тогда,когда это можно,так как изменение данных в процессе их анализа ни к чему хорошему не приводит.
   Aleksey
 
120 - 23.10.18 - 10:39
(115) Можно создать новый, но не добавить существующий. Вот в этом проблема

А из режима предприятия есть возможность добавить существующий без танцев с бубнами
   dk
 
121 - 23.10.18 - 11:09
чото вы тут все загоняетесь
vitkhv прав - создание вьюх решает и безопасность и скорость и веб сервисов не надо тьму писать
у нас в 77 тоже вьюхи генерятся - конфу обновили - запустили перегенерацию вьюх и все
   Cyberhawk
 
122 - 23.10.18 - 11:12
(121) За вьюхами следить надо на уровне изменений в источнике данных (талицах СУБД), а веб-сервис на 1С - только за изменениями на уровне метаданных конфигурации (включая расширения).
У первого частотность возникновения _всегда_ выше, чем у второго, поэтому очевидно, что и следить за реализацией по второму пути придется меньше, чем по первому.
   dk
 
123 - 23.10.18 - 11:14
что там следить то - поставь на автомат и забудь
   Cyberhawk
 
124 - 23.10.18 - 11:21
(123) Как предлагаешь этому автомату определять момент, когда уже пора обновить вьюшку?
   ADirks
 
125 - 23.10.18 - 11:25
(123) не знаю как в восьмёрке это сделать, но уверен, что можно, если подумать.
в семёрке просто: при старте смотрим дату 1cv7.md, сравниваем с константой, если различаются - обновляем.
   ADirks
 
126 - 23.10.18 - 11:29
Кроме того, вьюхи можно делать чуть сложнее, чем синонимичные. Можно написать некий запрос, собирающий данные из нескольких табличек, с какими-то преобразованиями, и всё что угодно. Пишешь такую вьюшку, и отдаешь её в стороннюю систему - и им проще, и тебе спокойнее.
   Cyberhawk
 
127 - 23.10.18 - 11:30
(126) "и тебе спокойнее" // Ошибаешься. Это явно не спокойнее, чем веб-/хттп-сервис 1С.
   ADirks
 
128 - 23.10.18 - 11:39
(127) и в чём принципиальная разница?
в обоих случаях отдаётся только та информация, которая нужна
   Cyberhawk
 
129 - 23.10.18 - 11:40
(128) См. (122)
   ADirks
 
130 - 23.10.18 - 11:44
(129) см (126)
подчёркиваю: у нас вьюхи руками никто не обновляет

не надо за этим следить
   Cyberhawk
 
131 - 23.10.18 - 11:45
(130) См. (124)
   vitkhv
 
132 - 23.10.18 - 13:20
(123) Хорошая идея
(131) по мотивам (123) при генерации вьюх сохраняем в отдельную таблицу:
SELECT  
      MAX([Modified])
      
  FROM [dbo].[Config]

потом роботом сравниваем опять с MAX(Modified) если больше сохраненной перегенирируем вьюхи.

Ну или тригер на конфиг повешать, но лучше не надо. не люблю тригеры.
   dmpl
 
133 - 23.10.18 - 13:23
А теперь представим, что 1С переименовала то поле, которое использует OLAP. Например, разбила его на 2. Или наоборот пару полей на один ключ аналитики повесило. И? Усё пропало? Во вьюхе больше нет такого поля. Переписывать ответную часть?
 
 
   APXi
 
134 - 23.10.18 - 13:25
(0) Пускай делают, только права на чтение дать и предупредить что структура может меняться при обновлении.
   Cool_Profi
 
135 - 23.10.18 - 13:27
(133) У тебя же есть уже генератор вьюх.
   vitkhv
 
136 - 23.10.18 - 13:32
(120) Не знал. Бухгалтеру такую возможность точно надо забанить, не его это дело.
   vitkhv
 
137 - 23.10.18 - 13:35
(133) проблема может возникнуть если 1С вдруг решит например из просто ссылочного поля сделать составное, тогда да, тогда придется переделывать. Но опять же, это не так уж сильно напрягает.
   ADirks
 
138 - 23.10.18 - 13:35
(133) или ответную часть, или вьюху - что-то переписать в любом случае придётся. Лучше вьюху.

(135) не, генератор генерит только вьюхи-синонимы. Для отдачи вовне лучше запилить специальную вьюху, и при изменениях в метаданных модифицировать именно её. Руками. В принципе, это ничем не отличается от веб-сервиса, чуть другие технические моменты.
   Cyberhawk
 
139 - 23.10.18 - 13:42
(132)
1. На какое событие вешать этого робота-анализатора?
2. Точно без изменения [dbo].[Config] не бывает изменения остальных таблиц (с данными)?
   vitkhv
 
140 - 23.10.18 - 13:43
(126) А еще такую вьюху, к нескольким таблицам, можно материлизовать, тогда если выборки с отборами, вообще все летать будет.
Да и вообще можно вьюху материализовывать с нужными тебе доп индексами, 1С в запросах к своим таблицам на которую смотрит материализованная вьюха, будет использовать индексы этой вьюхи.
   Cyberhawk
 
141 - 23.10.18 - 13:45
(138) "В принципе, это ничем не отличается от веб-сервиса" // Конечно же отличается: в случае изменения метаданных конфигурации ты _так и так_ эти изменения применяешь скорее всего в конфигураторе. И сразу же легко средствами конфигуратора находишь, что изменения затрагивают веб-/хттп-сервис.
А вот чтобы изменения в таблицах СУБД выявить, конфигуратором уже не обойдешься.
   vitkhv
 
142 - 23.10.18 - 13:46
(139) Точно. В этой таблице храниться вся конфа.
Робот из 1С, срабатывающий каждые 5 минут. Так пойдет?
   vitkhv
 
143 - 23.10.18 - 13:49
(141) Ну это скорее уже мелкие придирки.
Можно и до веб сервисов докопаться, если захотеть.
   Cyberhawk
 
144 - 23.10.18 - 13:54
(142) Вхолостую 99% времени дергать СУБД - может и ничего оно там не нагружает, но ведь костыль какой-то. Да и задержка может достигать эти 5 минут - это может быть критично для потребителя сервиса.
   Cyberhawk
 
145 - 23.10.18 - 13:55
(143) Это не придирки, это раскрытие описанного в (122) касательно частотности. В пофигуратор так и так лезть (в 100% случаев).
   dmpl
 
146 - 23.10.18 - 13:55
(138) Такую вьюху придется модифицировать и при изменении внутренней структуры хранения, а не только при изменении метаданных. Более того, оперируя понятиями только из 1С это делать удобнее.
   vitkhv
 
147 - 23.10.18 - 13:56
(144) Вы не видели какие запросы в холостую гоняет MDS от Майкрсофт когда опрашивает таблицы на изменения. Нет в этом ничего страшного ни с точки зрения БД, ни сточки зрения клиента в виде 1С.
   Cyberhawk
 
148 - 23.10.18 - 14:01
(147) Я ж не спорю - наоборот, вполне допускаю, что с точки зрения нагрузки такой "холостой долбеж" никаких последствий вообще не имеет.
Но архитектурно все равно не нравится. Это как из 1С долбить регистр сведений на предмет появления новой записи в логе телефонии, чтоб открыть пользователю карточку звонящего при входящем звонке - тоже "холостой долбеж" 99% времени.
Но вон телефония уже научилась сама стучать по событиям и это конечно кошерно.
Вот и с вьюхами бы так - пусть оно само там определяет, когда надо пересоздать, и пересоздает. Это ты про триггеры и имел в виду наверное?
   vitkhv
 
149 - 23.10.18 - 14:15
(148) Ну да можно тригер повесить на изменение, но что этот тригер будет запускать? Нам же по идее надо вызвать 1С и выполнить в ней алгоритм перегенерации вьюх.
 
 Рекламное место пустует
   Cyberhawk
 
150 - 23.10.18 - 14:16
(149) Вот в примере выше с телефонией АТС умеет дергать ХТТП-сервис инфобазы 1С. В скуле бы так )
   vitkhv
 
151 - 23.10.18 - 14:21
(148) Из тригера стучаться по Com к 1С, это жесть полная.  Хотя как я знаю есть один любитель делать обмены на тригерах, он даже статью на инфостарте вроде писал по этому поводу.
   Cyberhawk
 
152 - 23.10.18 - 14:22
Не, СОМ конечно же не надо
   igork1966
 
153 - 23.10.18 - 14:23
(34) "А так же за любые последствия (явные и неявные), связанные с нарушением лицензионного соглашения 1С"

Ты думаешь что таким способом ты снимешь ответственность?
Сильно сомневаюсь. Только подтвердишь что при реализации нарушается лицензионное соглашение. От потенциального суда это не спасет. Или расчет что заказчик откажется?
   vitkhv
 
154 - 23.10.18 - 14:24
(150) А почему нет? Вообще в принципе запросы на опрос таблиц на изменение с определенной периодичностью плохим тоном не считается. Так в принципе многие делают, чтобы триггеры не юзать.
   Shur1cIT
 
155 - 23.10.18 - 14:27
(0) как всегда всё не читал,
у нас HTTP сервисы нам шлют запрос JSON в нем в обратку шлём,аналогично и мы забираем чрез api сервера.При этом не надо заморачиваться о внутреннем устройстве стороннего ПО и его БД.
это наиболее правильный и современный способ взаимодействовать между двумя по, ну еще более правильно сервис очереди организовать, но для нас это излишне.
   ADirks
 
156 - 23.10.18 - 14:30
(154) 1C тоже так делает :))
и дело тут даже не в триггерах
   vitkhv
 
157 - 23.10.18 - 14:32
(153) Лицензионное соглашение от 1С противоретичит законодательству РФ в области правобладания. Единственное, что нельзя по нашему законодательству делать, это увеличивать количество пользователей, а так после покупки ПО ты можешь модернизировать его как хочешь. И по этому не было ни одного прецедента, по преследованию со стороны 1С таких случаев. На Хабре это лицензионное соглашение разбиралось по косточкам.
Суть соглашения, если ты полез напрямую, то 1С от тебя отмораживается, вот и вся его суть.
   vitkhv
 
158 - 23.10.18 - 14:37
(156) Да хотел написать, что и 1С так делает.))))
Вообще наоборот использование триггеров является плохим тоном в разработке БД.
   Cool_Profi
 
159 - 23.10.18 - 14:41
(158) @использование триггеров является плохим тоном в разработке БД@

Откуда дровишки?
   vitkhv
 
160 - 23.10.18 - 14:47
(159)Ну как бы часто такое проскальзывает в обсуждениях на SQL.ru.
ну как пример http://www.sql.ru/forum/1126731/ne-ponyatnoe-povedenie-triggerov?hl=%f2%f0%e8%e3%e3%e5%f0%fb%20%ef%eb%ee%f5%ee%e9%20%f2%ee%ed
   vitkhv
 
161 - 23.10.18 - 14:48
(159) Ну и как бы уже 15 лет с MSSQL это почти как аксиома.
   ADirks
 
162 - 23.10.18 - 14:49
(158) Ну, злоупотреблять конечно не стоит. Если в прикладной системе есть нужные события - то пользуемся ими. Но иной раз триггеры - единственно возможный выход. Делал как-то двусторонний обмен с польской программой для расчета окон, так пара триггеров и табличек-очередей решили вопрос. И куча вьюх, да. Поляки потом перенимать опыт приезжали :)
Или например формирование всяких вспомогательных табличек, протоколы там всякие - самый надёжный метод.
   vitkhv
 
163 - 23.10.18 - 14:51
(162) Скажем так, если можно обойтись без триггера то его задействовать не стоит.
А так да, в момент моей молодости много чего под 77 на триггерах делал. Потом отучился.
   Сияющий в темноте
 
164 - 23.10.18 - 21:28
С триггерами есть некоторая проблема в оптимизации запросов и пакетном добавлении,когда sql сервер не знает,что будет выполняться в триггере и быстрое добавление в таблицу может обернуться тормозами и блокировками.
Если триггер никуда,кроме самой записи не пишет,то таких проблем нет,но и отслеживание таким триггером не сделаешь.
   Nyarlathotep
 
165 - 23.10.18 - 22:09
(0) Я не пойму - а чем тебе не нравиться, что они что-то там забирают из базы SQL напрямую? Это нормально... Они же туда ничего не пишут, правильно? Их внешняя система - это их зона ответственности, пусть забирают то, что нужно и сами там разбираются. Тебе то какая разница? Ты просто предупреди их, что с обновлением релиза может измениться структура и наборы таблиц и все, дальше пусть сами.
   Nyarlathotep
 
166 - 23.10.18 - 22:13
(0) А если не хочешь их в базу пускать - тогда да, сделай или веб-сервис, или буферную базу/таблицу в sql, куда сливай нужные им данные, а они пусть забирают.
   Nyarlathotep
 
167 - 23.10.18 - 22:20
По поводу же минусов прямых запросов - их нет. Прямой запрос сработает значительно быстрее написанного на языке запросов 1с. Единственное что - тебе придется самому собирать нужные данные из всей этой мошны 1с-ных таблиц. Но это трудно только в первый раз)))
   vs84
 
168 - 24.10.18 - 00:17
(167) [Прямой запрос сработает значительно быстрее написанного на языке запросов 1с.]

Можно подумать, запросы из 1С шлют не прямые запросы на скл - через прослойку сервера, но точно не о каком "значительно" речи не идет.
   vs84
 
169 - 24.10.18 - 00:25
(0) если есть прямая доступность от получателя до скл базы, то вполне можно напрямую, почему нет. вьюхи (приведенные к человеческим именам метаданных) хороший способ. Аргументы про то, что структура меняется и "шеф все пропало" несерьезные - даже если не автоматизировать переформирование вьюх по актуальной структуре хранения, то частота с которой возникает изменение имен хранения делает ту проблему ничтожной.
   Tonik992
 
170 - 24.10.18 - 00:28
(168) Прямой запрос в SSMS будет быстрее, чем где бы то ни было. -)
Впринципе можно отказаться от пользовательского интерфейса, все делать на sql скриптах.
   Злопчинский
 
171 - 24.10.18 - 00:51
(170) можно вообще от 1С отказаться, зачем лишние проклдадки в достижении результата
   dmpl
 
172 - 24.10.18 - 07:05
(168) Ну... это можете втирать тем, кто не видел ЧТО сервер шлет в запросах.
   Cyberhawk
 
173 - 24.10.18 - 07:34
(169) "даже если не автоматизировать переформирование вьюх ...  то частота с которой возникает изменение имен хранения делает ту проблему ничтожной" // Как лихо ты отнес недоступность сервиса для потребителя к ничтожной проблеме, однако...
   Vladal
 
174 - 24.10.18 - 08:52
(0) "У клиентов периодически возникает потребность забирать данные из 1С в какую-то другую внешнюю систему (OLAP и т. д.). "

Для этого есть Automation
   vitkhv
 
175 - 24.10.18 - 09:13
(167) Нет там никакого быстрее,если не извращаешся с кучей точек в соединениях и виртуальными таблицами в соединениях. Работают с точно такой же скоростью. Это если запросы одинаковые по подходу в написании. А вот когда начинаешь использовать всякие плюхи в виде великого и могучего T-SQL, ну типа CTE для замены в ИЕРАРХИИ() или для того же разузлования. Запросы к JSON, OPENROWSET, For XML, CLR, самописные функции в запросах, кореллированные подзапросы (1С умеет их только в секции WHERE) , да те же строковые функции TSQL. Тогда да, работает действительно быстрее. И операции модификации таблиц, вот это точно намного быстрее, т.к. 1С умеет только в построчную модификацию.
   dezss
 
176 - 24.10.18 - 10:05
(102) (175) а можешь показать какой-то конкретный пример как делать вьюхи из 1с?
или пни меня, плз, в нужном направлении, типа гайда "как создать вьюху для чайников")
   Cyberhawk
 
177 - 24.10.18 - 10:15
(176) Из 1С просто запускается запрос к СУБД, в справке к create view все описано
   vitkhv
 
178 - 24.10.18 - 10:29
(176) ПолучитьСтруктуруХраненияБД(,Истина)
потом генерируешь текст вьюх и через ADO их создаешь.
   vitkhv
 
179 - 24.10.18 - 10:33
(176)
Если захочешь использовать точки в таких конструкциях типа Справочник.Номенклатура, обрамляй их []
   vitkhv
 
180 - 24.10.18 - 10:38
(176) ну и если захочешь сам генерировать GUID в стандарте 1С из MSSQL при создании объектов или на операциях вставки, прочитай вот эти темы:
http://www.sql.ru/forum/1301722-a/guid-iz-1s-v-ms-sql-i-obratno-kak-realizovyvaetsya

и
http://www.sql.ru/forum/1289996-a/dannye-1s

там есть примеры функций преобразования кроме пожалуй функции сгенерированной NEWSEQUENTIALID( ), но и эта функция у меня есть.
   vitkhv
 
181 - 24.10.18 - 10:45
(176) и не забудь про перечисления, для них у меня отдельная таблица, вьюхь на них лучше не вешать т.к. будет множество юнионов по количеству перечеслений (каждое перечисление в отдельной таблице) и оптимизатор это запрос не сможет правильно обработать, ну либо материализуй такую вьюху.
   dezss
 
182 - 24.10.18 - 11:27
(177) (181) спасибо, почитаю
   Асем
 
183 - 24.10.18 - 11:28
Здравствуйте!
Сижу в Sql с таблицами с 1 с
Нужно найти в них факты продаж
c kakimi tablicami luchwe rabotat'?
   Botanik8888
 
184 - 24.10.18 - 12:26
(183) это очевидно... с продажными
   vitkhv
 
185 - 24.10.18 - 14:04
(183) Если УТ 10x или УПП, то можно использовать регистр накопления продажи.
Но понятие регистр в 1С это несколько таблиц, с которыми вам предстоит разобраться. Проще всего, через профайлер посмотреть как 1С строит запросы к этому регистру.
   GANR
 
186 - 25.10.18 - 13:11
А кто-нибудь задумывался, если скажем понадобятся остатки из регистров накопления? Представляете какую страхотень придется городить? Тут уже вьюхи не помогут.
   dk
 
187 - 25.10.18 - 13:39
(186) дык профайлер никто не отменял
копипастишь изапрос из профайлера
   VitShvets
 
188 - 25.10.18 - 20:42
(187) Потом выкидываешь получившийся ужос и пишешь нормально :)
Но на посмотреть как принципиально это работает, можно.
   VitShvets
 
189 - 25.10.18 - 20:46
(186) Если речь об оперативных остатках, это простейший селект к таблице итогов с отборами по дате(5999-11-01) и по складам-товарам, в соответствии с бизнес логикой. Сложнее с получением остатков "на дату", но и там не сложно - суммируется 2 выборки - ближайшие итоги и обороты за дельту дат.
   МихаилМ
 
190 - 25.10.18 - 21:08
(186) давно задумались . еще создатели 1с++ . запрос простой с учетом , что из итогов можно и вычитать .
   Злопчинский
 
191 - 25.10.18 - 23:43
(189) дадада, еще характеристики, серийный учет и прочая развесистость
   Сергиус
 
192 - 26.10.18 - 00:58
(0)Главный минус, это то, что надо знать структуру таблиц и колонок. Если знаешь, то почему бы и нет. Но лучше конечно через родной механизм 1с.
   МихаилМ
 
193 - 26.10.18 - 02:43
(192) парсите конфиг , через dbnames сопоставляете имена полей и таблиц, храните сопоставление , далее парсите и сопоставляете в триггере только при изменении config .
изредка 1с меняет структуру хранения данных , как с константами.
   VitShvets
 
194 - 26.10.18 - 13:44
(191) Это вопрос к перечню полей в group by, не более.
   Demiurg
 
195 - 27.10.18 - 11:33
(0) кроме минусов есть и плюсы, можно READ UNCOMMITTED зарядить, указать в хинтах maxdop и т.п.
так что если 1С-кам жить не мешают, то вам то что
тем более если что работать не будет, сразу на них свалите )))
  1  2

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует