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

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

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

Минусы прямых запросов к  1С8
Я
   zavyzka
 
22.10.18 - 16:20
У клиентов периодически возникает потребность забирать данные из 1С в какую-то другую внешнюю систему (OLAP и т. д.). Рзаработчики внешних систем всегда предлагают забирать на прямую из ms sql. Я обычно говорю, что это плохое решение и лучше подключаться к 1С, а не к ms sql. Но исчерпывающих доводов, почему плохо забирать из sql предоставить не могу. Просьба поделиться мыслями на эту тему.
 
 
   Волшебник
 
1 - 22.10.18 - 16:21
Потому что это нарушает лицензионное соглашение 1С.
Кроме того, они не смогут расшифровать структуру, если вдруг 1С решит сменить структуру хранения данных в очередном релизе.
   Вафель
 
2 - 22.10.18 - 16:22
лучше вебсервис написать
   Fragster
 
3 - 22.10.18 - 16:24
потому что ты не контролируешь, что они будут делать в базе. правильно дать им odata доступ под пользователем со строго ограниченными правами
   Fragster
 
4 - 22.10.18 - 16:25
или регламентировать формат данных и написать веб сервис
   zavyzka
 
5 - 22.10.18 - 16:25
(1) про первый пункт понятно. А про второй, я вроде бы слышал, что обновлении/реструктаризации 1С может получиться так что название и структура регистра в 1С осталась прежней, а имя таблицы в sql поменялось. Или я что то путаю?
   Волшебник
 
6 - 22.10.18 - 16:26
(5) Всё возможно.
   vitkhv
 
7 - 22.10.18 - 16:27
(1) В 1С есть ПолучитьСтруктуруХранения БД. Если сменят структуру функция выдаст эту структуру.
   zavyzka
 
8 - 22.10.18 - 16:27
(2) (4) ну да это правильно, но это трудозатраты разработчика 1С, в отличии от обращения на пряму.
   vitkhv
 
9 - 22.10.18 - 16:28
(5) VIEW решают проблему смены имен таблиц
   Волшебник
 
10 - 22.10.18 - 16:29
(9) 1С может снести все вьюшки, которые ей не нужны.
 
 Рекламное место пустует
   vitkhv
 
11 - 22.10.18 - 16:30
(10) Кто мешает пересоздать после реструтуризации?
   Волшебник
 
12 - 22.10.18 - 16:31
(11) Вот нахер нужен весь этот геморрой?
   vitkhv
 
13 - 22.10.18 - 16:32
(12) да вот тот же OLAP
   vitkhv
 
14 - 22.10.18 - 16:33
(12) разузлование у меня через CTE и обмены между БД.
   gantonio
 
15 - 22.10.18 - 16:34
не отнимай у коллег хлеб, и они не будут делать тоже самое .. пусть тр-ся.
   Волшебник
 
16 - 22.10.18 - 16:34
(13) Всё это очень рискованно. В любой момент всё сломается и придётся всё переделывать практически с нуля.
   vitkhv
 
17 - 22.10.18 - 16:35
(16) не верю в шаманство, все работает годами
   Волшебник
 
18 - 22.10.18 - 16:38
(17) Всё сломается в самый неподходящий момент, когда ты уволишься.
   МихаилМ
 
19 - 22.10.18 - 16:39
риски переименования таблиц 1с8 минимальны, с 8.2.13 в 1с8
есть таблица сопоставления полей и таблиц метаданным.

но изредка 1с меняет имена таблиц (вместо reg - rg например).
   vitkhv
 
20 - 22.10.18 - 16:44
(18) Да специалист немного другой уже нужен, а не просто 1С ник.
(19)
Приятней работать так
SELECT Ссылка FROM [Справочник.Номенклатура]
чем
SELECT _IDRRref FROM _Reference172

И если работает несколько разработчиков и обновления накатываются через объединение конф, всегда есть риск получить другое имя таблицы или поля на продакшен базе.
   Вафель
 
21 - 22.10.18 - 16:47
(3) можно дать доступ только на чтение
   Вафель
 
22 - 22.10.18 - 16:48
(18) Это как раз нормальный момент. хуже всего когда ты в отпуск собрался и у тебя уже билет и надо бежать, а тут все сломалось и нужно задержаться и чинить
   Cyberhawk
 
23 - 22.10.18 - 16:53
(22) Ну это уже ССЗБ. Ибо зачем, зная что есть вероятность "задержаться и чинить" организовывать отпуск так, чтоб "надо бежать"?
   Вафель
 
24 - 22.10.18 - 16:56
(23) пусть будет не отпуск. пусть у тебе просто нужно сегодня пораньше уйти
   Cool_Profi
 
25 - 22.10.18 - 16:56
(23) Сделать хорошо могут немногие. Сломать - может любой.
Я в 2 часа ночи скуль-базу поднимал после того, как трактор кабель перерубил...
   Cyberhawk
 
26 - 22.10.18 - 16:58
(24) Не ощущаю разницы. Как может быть "нужно пораньше уйти", если всегда есть вероятность, что "нужно задержаться и чинить"? Это друг с другом не вяжется.
   Cyberhawk
 
27 - 22.10.18 - 16:58
(25) Хз о чем ты
   Cool_Profi
 
28 - 22.10.18 - 16:58
(27) А ты вообще з о чём-то?
   Cyberhawk
 
29 - 22.10.18 - 17:00
(28) См. (26)
   Вафель
 
30 - 22.10.18 - 17:02
Всегда есть вероятность и иногда нужно пораньше уйти.
ну и к томуже есть законы Мерфи
   GANR
 
31 - 22.10.18 - 17:04
(0) Первая же выгрузка/загрузка базы через ДТ переименует все таблицы в MS SQL базе. Это значит единственный приемлемый способ снять/загрузить архив - бэкап. На тестовый стенд необходимо только через бэкап переносить.
   Вафель
 
32 - 22.10.18 - 17:05
(31) дт не рекомендуемый способ делать архив
   Cyberhawk
 
33 - 22.10.18 - 17:05
(30) Если ты знаешь, что вероятность есть всегда, то ставить себя в условие "нужно пораньше уйти" - тупо
 
 
   unregistered
 
34 - 22.10.18 - 17:06
(0) Предложи своим заказчикам самостоятельно неси ответственность за любые сбои, которые могут возникнуть в том случае, если 1С изменит структуру хранения данных, а так же если эта структура будет меняться при обновлениях конфигурации с реструктуризацией таблиц БД.
А так же за любые последствия (явные и неявные), связанные с нарушением лицензионного соглашения 1С, касающегося прямого доступа к данным средствами СУБД в обход механизмов платформы.

Обязательно включи эти два пункта в договор или допсоглашение к договору, или оформи документально любым другим способом.

Если заказчик готов брать на себя такие риски - ради бога.
Однако в 99% случаев заказчик спускается на землю, вытирает растёкшиеся слюни, закатывает обратно раскатанную губу и переводит разговор в более конструктивное русло, например (2) - написания веб-сервисов.
   Вафель
 
35 - 22.10.18 - 17:07
(33) не все в жизни зависит от нас. бвает и форс мажор
   GANR
 
36 - 22.10.18 - 17:07
Самое поганое - читать разработанные ими мозгодробильные запросы в виде (20)
   Cyberhawk
 
37 - 22.10.18 - 17:08
(35) Что-то ты повторяешь как (25)
   Cyberhawk
 
38 - 22.10.18 - 17:08
Вафель наведи мышкой на ссылку на второй пост в посте (34) - сообщение не входит в экран. Надо чтоб оно влево выдвигалось, а не вправо в таких случаях. Когда починишь? ))
   Вафель
 
39 - 22.10.18 - 17:11
(38) покажи скриншот
   unregistered
 
40 - 22.10.18 - 17:11
(32) > дт не рекомендуемый способ делать архив

Да. Но и не запрещенный.
Многие таким образом страхуются - иметь архив созданный средствами СУБД и архив средствами 1С.
В случае глобального сбоя может возникнуть ситуация, когда единственным работоспособным архивом окажется именно 1С-овский DT-шник.
   Cyberhawk
 
41 - 22.10.18 - 17:12
   Cyberhawk
 
42 - 22.10.18 - 17:13
(40) Я называю этот *.dt-файл "профилактическим бекапом" )
   Tonik992
 
43 - 22.10.18 - 17:15
(40) А почему не рекомендуемый?
   Tonik992
 
44 - 22.10.18 - 17:19
(43) нашел уже тему, спс
   Вафель
 
45 - 22.10.18 - 17:20
(41) у меня все норм
https://i.imgur.com/bCSnOY3.png
)))
   unregistered
 
46 - 22.10.18 - 17:21
(43) Именно потому, что см. (31): "Первая же выгрузка/загрузка базы через ДТ переименует все таблицы в MS SQL базе."

Выгрузка в DT - это не точная копия базы (не один в один). Это прочитали данные в таблицах СУБД и записали в другом виде (внутренний формат 1С - DT). По дороге может что-то поменяться.
Вплоть до того, что бывали случаи, когда база загруженная из DT была неработоспособна (или вообще создание базы из DT было невозможно), а при этом база продолжала себе работать на СУБД и из архивов, сделанных средствами СУБД.
   Cyberhawk
 
47 - 22.10.18 - 17:25
(45) Ну, была бы ссылка на пост ближе к краю, оно бы не влезло
   Вафель
 
48 - 22.10.18 - 17:26
(47) скрипт опен-сорс можешь допилить
   Cyberhawk
 
49 - 22.10.18 - 17:27
(48) Не волоку в этом вообще
 
 Рекламное место пустует
   Вафель
 
50 - 22.10.18 - 17:28
я react.mista пользуюсь, поэтому скрипт врядли уже буду дописывать
   vitkhv
 
51 - 22.10.18 - 17:32
(36) Да это жесть. Поэтому только VIEW
   Tonik992
 
52 - 22.10.18 - 17:33
(46) Не встречался с таким, но буду знать. Спасибо
   vitkhv
 
53 - 22.10.18 - 17:38
(31) Да пофиг это переименование. Просто вьюхи перегенирирую.
Я все равно не пишу так:
SELECT _IDRRref FROM _Reference172
а пишу через вьюхи, вот так 
SELECT Ссылка FROM [Справочник.Номенклатура]

я смотрю тут даже народ и не знает, что такое view и продолжает напирать на переименование.
   Вафель
 
54 - 22.10.18 - 17:39
(53) но вьюху то нужно не забыть перегенерить
   vitkhv
 
55 - 22.10.18 - 17:40
(54) ну если ты из DT решил базу загрузить, то я думаю не забудешь.
   Cyberhawk
 
56 - 22.10.18 - 17:41
(50) О пля, а там-то все кошерно: https://www.dropbox.com/s/k2zriojsc0i7iwc/Screenshot%202018-10-22%2017.39.42.png?dl=0
Но нет быстрого перехода к списку своих тем и к последнему сообщению.
   zavyzka
 
57 - 22.10.18 - 17:41
Всё равно про DT аргумент хороший.

Мне больше нравиться вариант когда к базе подключаются по COM, по тому что тут со строны 1С-ника минимальные трудозатраты, но я так понимаю, что тот же OLAP не сможет такое сделать, хотя например у QlikView есть свой коннектер.
   Cyberhawk
 
58 - 22.10.18 - 17:41
(55) Конечно же забудешь. Должно быть автоматизированно все.
   Cool_Profi
 
59 - 22.10.18 - 17:42
(57) А кто олапу запретит подключиться?
   vitkhv
 
60 - 22.10.18 - 17:42
(57) я за свою жизнь ни разу из DT в продакшен не грузил.
   vitkhv
 
61 - 22.10.18 - 17:43
(58) ну кто мешает? Поставь регламентное задание, каждую ночь перегенируй вьюхи.
   zavyzka
 
62 - 22.10.18 - 17:43
(59) я просто не в теме, но человек который занимется кубом сказал, что это невозможно.
   vitkhv
 
63 - 22.10.18 - 17:46
(59) Вон Power BI GUID не понимает, так что для него надо их в текстовый вид переводить, в той же вьюхе
   Cyberhawk
 
64 - 22.10.18 - 17:50
(61) Так вьюхи-то нужны сразу после завершения обновления
   vitkhv
 
65 - 22.10.18 - 17:51
(64) ну если ты только эту таблицу мучаешь, на которую вьюха смотрит.
   vitkhv
 
66 - 22.10.18 - 17:53
(64) Я вон даже экспериментировал с прикручиванием Excel морды к 1С через MDS. Даже сделал, но зарубили задачу.
   vitkhv
 
67 - 22.10.18 - 17:57
(64) Colum Store индексы на 1С таблицы делал, с получением adaptive join.
   Сияющий в темноте
 
68 - 22.10.18 - 18:42
Чего так бояться переименования таблиц,когда 1с и метаданные переименовывает,например,последнее 10.3.48.1 обновление для ут очень много чего меняеи,и даже если вы кошерно лезли через 1с,то все равно все переписывать
   unregistered
 
69 - 22.10.18 - 19:13
Любые подобные решения хороши, пока их автор и специалист отвечающий за поддержку работоспособности решений - это одно и то же лицо и это лицо является наёмным работником предприятия, где эти решения применяются.

В противном случае это перестаёт быть надёжным механизмом. Ибо зависит от многих нестабильных переменных факторов никак не подчинаяющихся автору.

(53) Никто не говорит, что оно неработоспособно или плохо (если закрыть глаза и пренебречь тонкостями лицензионного соглашения).
Просто есть нюансы, которые надо знать перед тем, как решиться на использование прямых запросов.
И тут речь не об 1С, а о любом программном продукте, чьи недокументированные или запрещенные вендором возможности ты используешь.

PS Очень мало существует реальных задач, где действительно необходимы прямые запросы и совершенно никак нельзя обойтись другими способами, как например веб-сервисы (куда более надёжными и стабильными).
   palsergeich
 
70 - 22.10.18 - 19:23
В теме не указана одна маленькая но крайне существенная вещь.
Любое использование не общепринятого функционала увеличивает стоимость поддержки, причем существенно.
Взять на пример тот же Инталев, который такими вещами злоупотребляет, и посмотреть количество внедрений хотя бы то тем же отзывам о внедрениях https://www.intalev.ru/products/km/clients/customer_reviews/ и можно увидеть дно - за 2 года 5 проектов.
Сам я с ним не работал в боевом применении, только поковырял немного, а вот коллеги работали и плюются.
Прелесть 1с в том, что если конфигурацию писали не марсиане, по после смены исполнителей можно относительно быстро найти людей которые и дальше смогут работать с этим продуктом
   palsergeich
 
71 - 22.10.18 - 19:24
Конечно, есть места где прямые запросы жизнено необходимы, например в таких случаях Секционирование регистра накопления но пихать их везде - не стоит
   DrZombi
 
72 - 22.10.18 - 20:13
(0) Через SQL быстрее, да пережить изменение структуры можно :)

Мона использовать в SQL представления, главное енто дело обновлять :)
https://www.sql.ru/docs/sql/u_sql/ch20.shtml
   DrZombi
 
73 - 22.10.18 - 20:14
+ Элементы справочников в другой БД ненужны, нужны только конкретные данные: Наименование, Суммы, галочки :)
   DrZombi
 
75 - 22.10.18 - 20:16
+ Дата, т.е. простые типы :)
   dmpl
 
76 - 22.10.18 - 20:27
(53) И сколько там переключений раскладки получается?
   vde69
 
77 - 22.10.18 - 21:06
самый главный агрумент : грузить из SQL нафига когда есть штатные механизмы 1с?

То есть пусть ОНИ пусть придумывают аргументы, а ты их всегда сможешь посылать типа "у меня будут блокировки, 1с не сможет гарантировать чистое чтение не штатными средствами, безопасность страдает, не дам прясмой доступ, боюсь, что все дропните и т.д."
   rsv
 
78 - 22.10.18 - 21:17
(0) так что предложить разоабочикаи внешних систем дабы они штатно забирали данные из 1с?
   rsv
 
79 - 22.10.18 - 21:18
Веб сервис на стороне 1С ...подсаживаетесь на вебсервер и простыни xml soap.
   VitShvets
 
80 - 22.10.18 - 21:21
Имхо, прямые запросы хорошая штука, когда точно понимаешь зачем это нужно и каковы последствия. Мы используем для OLAP, из за скорости - разница получения сырых данных перед процессингом огромная. Плюс используем секционирование на некоторых таблицах, CDC и компрессию таблиц/индексов. Да, есть минус, после выкладывания на боевую систему, требуется дополнительные действия навроде пересоздания view или пере-подключения таблицы к CDC, но, цель оправдывает средства.

НО! Я бы не стал рекомендовать такой подход, когда внедренцы приходящие. За этим зоопарком нужно, мягко говоря, присматривать.

(79) Если объемы данных позволяют, можно с помощью ADO выкладывать данные в интеграционные таблицы средствами 1С.
   rsv
 
81 - 22.10.18 - 21:24
Com ? А разве разработчикам внешних систем интересно копаться в прикладном описании com?методы тама 1сные и прочее

Им подавай простые вьюхи и примитивные типы строка число дата как в (80) т.к это самый быстрый способ и понятныйа
   zavyzka
 
82 - 22.10.18 - 23:27
(81) разработчикам внешних систем как раз и не предлагается копаться. 1С-ник за минуту делает какой нибудь запрос по регистру продаж с нужными полями и отдает запрос внешнему разработчику. Ну я когда интегрировался с QlikView мы так и делали, а с OLAP так не получается...
   dmpl
 
83 - 23.10.18 - 07:06
(82) Это просто отсталая технология. А может просто внедренцы не умеют в OLAP, вот и вешают лапшу...
   Dotoshin
 
84 - 23.10.18 - 08:08
(18) +100500
(17) Не работает это годами. У нас на предприятии, еще до меня, кто-то сделал OLAP как раз на прямых запросах. После очередного обновления платформы все сломалось. Было очень печально...
   Aleksey
 
85 - 23.10.18 - 08:12
По поводу смены имени таблицы

Сложнее обстоят дела, когда расширение модифицирует уже существующую структуру данных. Если расширение добавляет собственный реквизит к справочнику прикладного решения, то для этого справочника создаётся отдельная таблица с новой структурой (с дополнительной колонкой для нового реквизита). Будем называть её расширенная таблица. В неё переносятся данные из старой таблицы справочника. В дальнейшем все обращения к этому справочнику будут переадресовываться к расширенной таблице.
(с) https://wonderland.v8.1c.ru/blog/rasshirenie-dannykh/

Т.е. каждый раз когда мы решим добавить реквизит через расширение 1С создает новую таблицу. Так что я бы не сказал бы что риск смены имени минимальный
   Cyberhawk
 
86 - 23.10.18 - 08:34
(85) "каждый раз когда мы решим добавить реквизит через расширение 1С создает новую таблицу" // Не каждый, а первый
   vitkhv
 
87 - 23.10.18 - 08:52
(85) Ну и в чем здесь проблема? Пересоздать VIEW?
   vitkhv
 
88 - 23.10.18 - 08:54
(84) Прямые запросы разные бывают - если напрямую было сделано, тогда да, проблема, если через прокладку в виде вьюхи, то никаких проблем.
   Aleksey
 
89 - 23.10.18 - 09:00
(87) Проблема есть и очень большая.
Все работает ничего никто не менял, и тут раз всё сломалось? Как же так, никто ничего не обновлял вчера работало ... начинаешь выяснять 2 дня бегаешь в мыле в поисках виновных и в конечном итоги выясниться что бухгалтер подключил обработку которую дал ей банк для выгрузки заявок по заплатанному проекту. И пойти догадайся, что выгрузка ведомости на зарплату поломает тебе справочник контрагентов.

Хотя согласен, всегда можно сказать -  тю, разве это проблема?
   ptiz
 
90 - 23.10.18 - 09:00
(0) "Но исчерпывающих доводов, почему плохо забирать из sql предоставить не могу." - если нет вопросов с безопасностью (сольют всю базу), почему бы и не дать доступ + табличку со структурой - пусть сами тр..ся. А потом для профилактики загрузить базу из DT.
   Aleksey
 
91 - 23.10.18 - 09:02
И да загрузка базы из dt не ломает структуру. У меня куча копий на скуле и во всех имена таблиц одинаковые. Хотя я всё делаю исключительно через загрузку /выгрузки из dt
   vitkhv
 
92 - 23.10.18 - 09:14
(89) Ну если у вас бухгалтер самолично устанавливает обработку, у вас проблема с правами.
   vitkhv
 
93 - 23.10.18 - 09:16
(89)+бухгалтеру давать доступ к внешним обработкам это моветон, это дело программиста. Тем более если обработка встраивамая которая ломает структуру метаданных, т.е. бух. имеет доступ к конфигуратору, это вообще жесть. я такое не допускаю в принципе.
   END
 
94 - 23.10.18 - 09:17
(82) Расскажите вашим олапщикам про https://habr.com/post/330618/ SSIS и напиши им веб сервис. Пусть осваивают новые технологии :) Мы у себя сделали так.
   Cyberhawk
 
95 - 23.10.18 - 09:17
(92) Наверное он про расширение, что после его подключения оно добавляет новые реквизиты, то 1С реструктуризацию (в фоне) делает с переносом данных в новую таблицу.
Конечно в этом случае придется дополнительно следить за актуальностью вьюшки после любой манипуляции с расширениями.
Что он имел в виду под "обработкой" непонятно.
   vitkhv
 
96 - 23.10.18 - 09:19
(94) SSIS да хорошая вещь.
   vitkhv
 
97 - 23.10.18 - 09:20
(95) Так или иначе, если это делает бухгалтер - это немыслимо.
   Cyberhawk
 
98 - 23.10.18 - 09:21
(97) Если в организации уровень ИТ-потребностей таков, что там где-то используются вьюшки, тогда немыслимо )
   END
 
99 - 23.10.18 - 09:22
(96) И не говори. Правда пришлось сломать ментальное сопротивление олапщиков которые то же сначала хотели "SQL запросы прямые".
   dmpl
 
100 - 23.10.18 - 09:22
(87) И? Это разве не проблема при изменении структуры хранения? Оно делается автоматом, без затрат времени ИТ специалиста?
  1  2   

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