У клиентов периодически возникает потребность забирать данные из 1С в какую-то другую внешнюю систему (OLAP и т. д.). Рзаработчики внешних систем всегда предлагают забирать на прямую из ms sql. Я обычно говорю, что это плохое решение и лучше подключаться к 1С, а не к ms sql. Но исчерпывающих доводов, почему плохо забирать из sql предоставить не могу. Просьба поделиться мыслями на эту тему.

Потому что это нарушает лицензионное соглашение 1С.
Кроме того, они не смогут расшифровать структуру, если вдруг 1С решит сменить структуру хранения данных в очередном релизе.

лучше вебсервис написать

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

или регламентировать формат данных и написать веб сервис

(1) про первый пункт понятно. А про второй, я вроде бы слышал, что обновлении/реструктаризации 1С может получиться так что название и структура регистра в 1С осталась прежней, а имя таблицы в sql поменялось. Или я что то путаю?

(5) Всё возможно.

(1) В 1С есть ПолучитьСтруктуруХранения БД. Если сменят структуру функция выдаст эту структуру.

(2) (4) ну да это правильно, но это трудозатраты разработчика 1С, в отличии от обращения на пряму.

(5) VIEW решают проблему смены имен таблиц

(9) 1С может снести все вьюшки, которые ей не нужны.

(10) Кто мешает пересоздать после реструтуризации?

(11) Вот нахер нужен весь этот геморрой?

(12) да вот тот же OLAP

(12) разузлование у меня через CTE и обмены между БД.

не отнимай у коллег хлеб, и они не будут делать тоже самое .. пусть тр-ся.

(13) Всё это очень рискованно. В любой момент всё сломается и придётся всё переделывать практически с нуля.

(16) не верю в шаманство, все работает годами

(17) Всё сломается в самый неподходящий момент, когда ты уволишься.

риски переименования таблиц 1с8 минимальны, с 8.2.13 в 1с8
есть таблица сопоставления полей и таблиц метаданным.

но изредка 1с меняет имена таблиц (вместо reg - rg например).

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

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

(3) можно дать доступ только на чтение

(18) Это как раз нормальный момент. хуже всего когда ты в отпуск собрался и у тебя уже билет и надо бежать, а тут все сломалось и нужно задержаться и чинить

(22) Ну это уже ССЗБ. Ибо зачем, зная что есть вероятность "задержаться и чинить" организовывать отпуск так, чтоб "надо бежать"?

(23) пусть будет не отпуск. пусть у тебе просто нужно сегодня пораньше уйти

(23) Сделать хорошо могут немногие. Сломать - может любой.
Я в 2 часа ночи скуль-базу поднимал после того, как трактор кабель перерубил...

(24) Не ощущаю разницы. Как может быть "нужно пораньше уйти", если всегда есть вероятность, что "нужно задержаться и чинить"? Это друг с другом не вяжется.

(25) Хз о чем ты

(27) А ты вообще з о чём-то?

(28) См. (26)

Всегда есть вероятность и иногда нужно пораньше уйти.
ну и к томуже есть законы Мерфи

(0) Первая же выгрузка/загрузка базы через ДТ переименует все таблицы в MS SQL базе. Это значит единственный приемлемый способ снять/загрузить архив - бэкап. На тестовый стенд необходимо только через бэкап переносить.

(31) дт не рекомендуемый способ делать архив

(30) Если ты знаешь, что вероятность есть всегда, то ставить себя в условие "нужно пораньше уйти" - тупо

(0) Предложи своим заказчикам самостоятельно неси ответственность за любые сбои, которые могут возникнуть в том случае, если 1С изменит структуру хранения данных, а так же если эта структура будет меняться при обновлениях конфигурации с реструктуризацией таблиц БД.
А так же за любые последствия (явные и неявные), связанные с нарушением лицензионного соглашения 1С, касающегося прямого доступа к данным средствами СУБД в обход механизмов платформы.

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

Если заказчик готов брать на себя такие риски - ради бога.
Однако в 99% случаев заказчик спускается на землю, вытирает растёкшиеся слюни, закатывает обратно раскатанную губу и переводит разговор в более конструктивное русло, например (2) - написания веб-сервисов.

(33) не все в жизни зависит от нас. бвает и форс мажор

Самое поганое - читать разработанные ими мозгодробильные запросы в виде (20)

(35) Что-то ты повторяешь как (25)

Вафель наведи мышкой на ссылку на второй пост в посте (34) - сообщение не входит в экран. Надо чтоб оно влево выдвигалось, а не вправо в таких случаях. Когда починишь? ))

(38) покажи скриншот

(32) > дт не рекомендуемый способ делать архив

Да. Но и не запрещенный.
Многие таким образом страхуются - иметь архив созданный средствами СУБД и архив средствами 1С.
В случае глобального сбоя может возникнуть ситуация, когда единственным работоспособным архивом окажется именно 1С-овский DT-шник.

(39) https://www.dropbox.com/s/1wj4ny5wkyi2yc8/Screenshot%202018-10-22%2017.12.14.png?dl=0

(40) Я называю этот *.dt-файл "профилактическим бекапом" )

(40) А почему не рекомендуемый?

(43) нашел уже тему, спс

(41) у меня все норм
https://i.imgur.com/bCSnOY3.png
)))

(43) Именно потому, что см. (31): "Первая же выгрузка/загрузка базы через ДТ переименует все таблицы в MS SQL базе."

Выгрузка в DT - это не точная копия базы (не один в один). Это прочитали данные в таблицах СУБД и записали в другом виде (внутренний формат 1С - DT). По дороге может что-то поменяться.
Вплоть до того, что бывали случаи, когда база загруженная из DT была неработоспособна (или вообще создание базы из DT было невозможно), а при этом база продолжала себе работать на СУБД и из архивов, сделанных средствами СУБД.

(45) Ну, была бы ссылка на пост ближе к краю, оно бы не влезло

(47) скрипт опен-сорс можешь допилить

(48) Не волоку в этом вообще

я react.mista пользуюсь, поэтому скрипт врядли уже буду дописывать

(36) Да это жесть. Поэтому только VIEW

(46) Не встречался с таким, но буду знать. Спасибо

(31) Да пофиг это переименование. Просто вьюхи перегенирирую.
Я все равно не пишу так:
SELECT _IDRRref FROM _Reference172
а пишу через вьюхи, вот так
SELECT Ссылка FROM [Справочник.Номенклатура]

я смотрю тут даже народ и не знает, что такое view и продолжает напирать на переименование.

(53) но вьюху то нужно не забыть перегенерить

(54) ну если ты из DT решил базу загрузить, то я думаю не забудешь.

(50) О пля, а там-то все кошерно: https://www.dropbox.com/s/k2zriojsc0i7iwc/Screenshot%202018-10-22%2017.39.42.png?dl=0
Но нет быстрого перехода к списку своих тем и к последнему сообщению.

Всё равно про DT аргумент хороший.

Мне больше нравиться вариант когда к базе подключаются по COM, по тому что тут со строны 1С-ника минимальные трудозатраты, но я так понимаю, что тот же OLAP не сможет такое сделать, хотя например у QlikView есть свой коннектер.

(55) Конечно же забудешь. Должно быть автоматизированно все.

(57) А кто олапу запретит подключиться?

(57) я за свою жизнь ни разу из DT в продакшен не грузил.

(58) ну кто мешает? Поставь регламентное задание, каждую ночь перегенируй вьюхи.

(59) я просто не в теме, но человек который занимется кубом сказал, что это невозможно.

(59) Вон Power BI GUID не понимает, так что для него надо их в текстовый вид переводить, в той же вьюхе

(61) Так вьюхи-то нужны сразу после завершения обновления

(64) ну если ты только эту таблицу мучаешь, на которую вьюха смотрит.

(64) Я вон даже экспериментировал с прикручиванием Excel морды к 1С через MDS. Даже сделал, но зарубили задачу.

(64) Colum Store индексы на 1С таблицы делал, с получением adaptive join.

Чего так бояться переименования таблиц,когда 1с и метаданные переименовывает,например,последнее 10.3.48.1 обновление для ут очень много чего меняеи,и даже если вы кошерно лезли через 1с,то все равно все переписывать

Любые подобные решения хороши, пока их автор и специалист отвечающий за поддержку работоспособности решений - это одно и то же лицо и это лицо является наёмным работником предприятия, где эти решения применяются.

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

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

PS Очень мало существует реальных задач, где действительно необходимы прямые запросы и совершенно никак нельзя обойтись другими способами, как например веб-сервисы (куда более надёжными и стабильными).

В теме не указана одна маленькая но крайне существенная вещь.
Любое использование не общепринятого функционала увеличивает стоимость поддержки, причем существенно.
Взять на пример тот же Инталев, который такими вещами злоупотребляет, и посмотреть количество внедрений хотя бы то тем же отзывам о внедрениях https://www.intalev.ru/products/km/clients/customer_reviews/ и можно увидеть дно - за 2 года 5 проектов.
Сам я с ним не работал в боевом применении, только поковырял немного, а вот коллеги работали и плюются.
Прелесть 1с в том, что если конфигурацию писали не марсиане, по после смены исполнителей можно относительно быстро найти людей которые и дальше смогут работать с этим продуктом

Конечно, есть места где прямые запросы жизнено необходимы, например в таких случаях Секционирование регистра накопления но пихать их везде - не стоит

(0) Через SQL быстрее, да пережить изменение структуры можно :)

Мона использовать в SQL представления, главное енто дело обновлять :)
https://www.sql.ru/docs/sql/u_sql/ch20.shtml

+ Элементы справочников в другой БД ненужны, нужны только конкретные данные: Наименование, Суммы, галочки :)

+ Дата, т.е. простые типы :)

(53) И сколько там переключений раскладки получается?

самый главный агрумент : грузить из SQL нафига когда есть штатные механизмы 1с?

То есть пусть ОНИ пусть придумывают аргументы, а ты их всегда сможешь посылать типа "у меня будут блокировки, 1с не сможет гарантировать чистое чтение не штатными средствами, безопасность страдает, не дам прясмой доступ, боюсь, что все дропните и т.д."

(0) так что предложить разоабочикаи внешних систем дабы они штатно забирали данные из 1с?

Веб сервис на стороне 1С ...подсаживаетесь на вебсервер и простыни xml soap.

Имхо, прямые запросы хорошая штука, когда точно понимаешь зачем это нужно и каковы последствия. Мы используем для OLAP, из за скорости - разница получения сырых данных перед процессингом огромная. Плюс используем секционирование на некоторых таблицах, CDC и компрессию таблиц/индексов. Да, есть минус, после выкладывания на боевую систему, требуется дополнительные действия навроде пересоздания view или пере-подключения таблицы к CDC, но, цель оправдывает средства.

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

(79) Если объемы данных позволяют, можно с помощью ADO выкладывать данные в интеграционные таблицы средствами 1С.

Com ? А разве разработчикам внешних систем интересно копаться в прикладном описании com?методы тама 1сные и прочее

Им подавай простые вьюхи и примитивные типы строка число дата как в (80) т.к это самый быстрый способ и понятныйа

(81) разработчикам внешних систем как раз и не предлагается копаться. 1С-ник за минуту делает какой нибудь запрос по регистру продаж с нужными полями и отдает запрос внешнему разработчику. Ну я когда интегрировался с QlikView мы так и делали, а с OLAP так не получается...

(82) Это просто отсталая технология. А может просто внедренцы не умеют в OLAP, вот и вешают лапшу...

(18) +100500
(17) Не работает это годами. У нас на предприятии, еще до меня, кто-то сделал OLAP как раз на прямых запросах. После очередного обновления платформы все сломалось. Было очень печально...

По поводу смены имени таблицы

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

Т.е. каждый раз когда мы решим добавить реквизит через расширение 1С создает новую таблицу. Так что я бы не сказал бы что риск смены имени минимальный

(85) "каждый раз когда мы решим добавить реквизит через расширение 1С создает новую таблицу" // Не каждый, а первый

(85) Ну и в чем здесь проблема? Пересоздать VIEW?

(84) Прямые запросы разные бывают - если напрямую было сделано, тогда да, проблема, если через прокладку в виде вьюхи, то никаких проблем.

(87) Проблема есть и очень большая.
Все работает ничего никто не менял, и тут раз всё сломалось? Как же так, никто ничего не обновлял вчера работало ... начинаешь выяснять 2 дня бегаешь в мыле в поисках виновных и в конечном итоги выясниться что бухгалтер подключил обработку которую дал ей банк для выгрузки заявок по заплатанному проекту. И пойти догадайся, что выгрузка ведомости на зарплату поломает тебе справочник контрагентов.

Хотя согласен, всегда можно сказать -  тю, разве это проблема?

(0) "Но исчерпывающих доводов, почему плохо забирать из sql предоставить не могу." - если нет вопросов с безопасностью (сольют всю базу), почему бы и не дать доступ + табличку со структурой - пусть сами тр..ся. А потом для профилактики загрузить базу из DT.

И да загрузка базы из dt не ломает структуру. У меня куча копий на скуле и во всех имена таблиц одинаковые. Хотя я всё делаю исключительно через загрузку /выгрузки из dt

(89) Ну если у вас бухгалтер самолично устанавливает обработку, у вас проблема с правами.

(89)+бухгалтеру давать доступ к внешним обработкам это моветон, это дело программиста. Тем более если обработка встраивамая которая ломает структуру метаданных, т.е. бух. имеет доступ к конфигуратору, это вообще жесть. я такое не допускаю в принципе.

(82) Расскажите вашим олапщикам про https://habr.com/post/330618/ SSIS и напиши им веб сервис. Пусть осваивают новые технологии :) Мы у себя сделали так.

(92) Наверное он про расширение, что после его подключения оно добавляет новые реквизиты, то 1С реструктуризацию (в фоне) делает с переносом данных в новую таблицу.
Конечно в этом случае придется дополнительно следить за актуальностью вьюшки после любой манипуляции с расширениями.
Что он имел в виду под "обработкой" непонятно.

(94) SSIS да хорошая вещь.

(95) Так или иначе, если это делает бухгалтер - это немыслимо.

(97) Если в организации уровень ИТ-потребностей таков, что там где-то используются вьюшки, тогда немыслимо )

(96) И не говори. Правда пришлось сломать ментальное сопротивление олапщиков которые то же сначала хотели "SQL запросы прямые".

(87) И? Это разве не проблема при изменении структуры хранения? Оно делается автоматом, без затрат времени ИТ специалиста?

(100) Да, автоматом по ночам.

(100) Из моей обработки, по созданию VIEW.

        
    ТекстПредставления="
        |DROP VIEW  IF EXISTS "+ИмяПредставления+"
        |go
        |
        |CREATE VIEW "+ИмяПредставления+"
        | AS
        |SELECT ";
Для Каждого КолонкиБД ИЗ  СтрокаБД.Поля Цикл
..............
КонецЦикла

(93) Ну хорошо бухгалтер принес обработку - "расширение".
Я знаю единственный способ добавить расширение - это через предприятие. Через конфигуратор у меня не получается добавить расширение. Научите.

(95) обработка в виде расширения

(100) Единственное для перечеслений я создаю отдельную таблицу и функцию dbo.ЗНАЧЕНИЕ. И в тексте запроса можно писать так:

WHERE Номенклатура.СтавкаНДС = dbo.ЗНАЧЕНИЕ('Перечисление.СтавкиНДС.НДС18')

(102) И эту обработку написать быстрее, чем сервис?

(106) Почему нет?

(103) "Через конфигуратор у меня не получается добавить расширение. Научите" // Там неочевидное приходится совершать - добавить новое расширение, а потом загрузить его конфигурацию из файла

(106) По крайней мере я напишу ее точно быстрее чем сервис.

(109) Сейчас-то да, а в первый раз?

(104) Я все расширения через конфигуратор добавляю, в чем проблема?

(110) В первый раз я свой парсер запросов написал. ))))

(111) Не создать, а подключить уже созданный файл *.cfe

(110) ТК в 2000 сервере нельзя было инсертить виев я про них забыл.

(113) через конфигуратор я расширения CFE подключаю. В чем проблема? Те же инструметы разработчика.

(113) Я честно говоря даже незнаю как их через предприятие подключать.

(106) Думаю что быстрее. Более того, написать такую обработку надо всего один раз, дальше оно само. И руками её запускать не нужно. Делается механизм, отслеживающий изменения конфигурации, и запускающий генерацию всего что нужно. Т.е. один раз сделали, и забыли навсегда.

вот где 1с , а гда олап ? Знаете, что в обработке данных для всяких статистических задач, как бы считается , что 60-80 процентов времени уходит на подготовку данных. Т.е. модель ищется серди мусора, данные чистятся ,находятся нужные.
А вы собираетесь реквизитик добавить , да и вообще сделать какую то проекцию в модель о которой вы ничего не понимаете. да с вами просто никто не хочет общаться на тему высоких материй.

Кстати,когда в какой то таблице в имя поля добавляется удалить,а новые поля не создаются,то таблица в Sql никак не меняется,и никто не узнает,что данных там уже нет.
Если анализ данных требует с ними выполнять множество преобразований,то все равно это будет делаться в отдельной базе,так что со стороны 1с можно написать план обмена,чтобы новую базу заполнять данными,причем тогда,когда это можно,так как изменение данных в процессе их анализа ни к чему хорошему не приводит.

(115) Можно создать новый, но не добавить существующий. Вот в этом проблема

А из режима предприятия есть возможность добавить существующий без танцев с бубнами

чото вы тут все загоняетесь
vitkhv прав - создание вьюх решает и безопасность и скорость и веб сервисов не надо тьму писать
у нас в 77 тоже вьюхи генерятся - конфу обновили - запустили перегенерацию вьюх и все

(121) За вьюхами следить надо на уровне изменений в источнике данных (талицах СУБД), а веб-сервис на 1С - только за изменениями на уровне метаданных конфигурации (включая расширения).
У первого частотность возникновения _всегда_ выше, чем у второго, поэтому очевидно, что и следить за реализацией по второму пути придется меньше, чем по первому.

что там следить то - поставь на автомат и забудь

(123) Как предлагаешь этому автомату определять момент, когда уже пора обновить вьюшку?

(123) не знаю как в восьмёрке это сделать, но уверен, что можно, если подумать.
в семёрке просто: при старте смотрим дату 1cv7.md, сравниваем с константой, если различаются - обновляем.

Кроме того, вьюхи можно делать чуть сложнее, чем синонимичные. Можно написать некий запрос, собирающий данные из нескольких табличек, с какими-то преобразованиями, и всё что угодно. Пишешь такую вьюшку, и отдаешь её в стороннюю систему - и им проще, и тебе спокойнее.

(126) "и тебе спокойнее" // Ошибаешься. Это явно не спокойнее, чем веб-/хттп-сервис 1С.

(127) и в чём принципиальная разница?
в обоих случаях отдаётся только та информация, которая нужна

(128) См. (122)

(129) см (126)

подчёркиваю: у нас вьюхи руками никто не обновляет

не надо за этим следить

(130) См. (124)

(123) Хорошая идея
(131) по мотивам (123) при генерации вьюх сохраняем в отдельную таблицу:
SELECT  
      MAX([Modified])
      
  FROM [dbo].[Config]

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

Ну или тригер на конфиг повешать, но лучше не надо. не люблю тригеры.

А теперь представим, что 1С переименовала то поле, которое использует OLAP. Например, разбила его на 2. Или наоборот пару полей на один ключ аналитики повесило. И? Усё пропало? Во вьюхе больше нет такого поля. Переписывать ответную часть?

(0) Пускай делают, только права на чтение дать и предупредить что структура может меняться при обновлении.

(133) У тебя же есть уже генератор вьюх.

(120) Не знал. Бухгалтеру такую возможность точно надо забанить, не его это дело.

(133) проблема может возникнуть если 1С вдруг решит например из просто ссылочного поля сделать составное, тогда да, тогда придется переделывать. Но опять же, это не так уж сильно напрягает.

(133) или ответную часть, или вьюху - что-то переписать в любом случае придётся. Лучше вьюху.

(135) не, генератор генерит только вьюхи-синонимы. Для отдачи вовне лучше запилить специальную вьюху, и при изменениях в метаданных модифицировать именно её. Руками. В принципе, это ничем не отличается от веб-сервиса, чуть другие технические моменты.

(132)
1. На какое событие вешать этого робота-анализатора?
2. Точно без изменения [dbo].[Config] не бывает изменения остальных таблиц (с данными)?

(126) А еще такую вьюху, к нескольким таблицам, можно материлизовать, тогда если выборки с отборами, вообще все летать будет.
Да и вообще можно вьюху материализовывать с нужными тебе доп индексами, 1С в запросах к своим таблицам на которую смотрит материализованная вьюха, будет использовать индексы этой вьюхи.

(138) "В принципе, это ничем не отличается от веб-сервиса" // Конечно же отличается: в случае изменения метаданных конфигурации ты _так и так_ эти изменения применяешь скорее всего в конфигураторе. И сразу же легко средствами конфигуратора находишь, что изменения затрагивают веб-/хттп-сервис.
А вот чтобы изменения в таблицах СУБД выявить, конфигуратором уже не обойдешься.

(139) Точно. В этой таблице храниться вся конфа.
Робот из 1С, срабатывающий каждые 5 минут. Так пойдет?

(141) Ну это скорее уже мелкие придирки.
Можно и до веб сервисов докопаться, если захотеть.

(142) Вхолостую 99% времени дергать СУБД - может и ничего оно там не нагружает, но ведь костыль какой-то. Да и задержка может достигать эти 5 минут - это может быть критично для потребителя сервиса.

(143) Это не придирки, это раскрытие описанного в (122) касательно частотности. В пофигуратор так и так лезть (в 100% случаев).

(138) Такую вьюху придется модифицировать и при изменении внутренней структуры хранения, а не только при изменении метаданных. Более того, оперируя понятиями только из 1С это делать удобнее.

(144) Вы не видели какие запросы в холостую гоняет MDS от Майкрсофт когда опрашивает таблицы на изменения. Нет в этом ничего страшного ни с точки зрения БД, ни сточки зрения клиента в виде 1С.

(147) Я ж не спорю - наоборот, вполне допускаю, что с точки зрения нагрузки такой "холостой долбеж" никаких последствий вообще не имеет.
Но архитектурно все равно не нравится. Это как из 1С долбить регистр сведений на предмет появления новой записи в логе телефонии, чтоб открыть пользователю карточку звонящего при входящем звонке - тоже "холостой долбеж" 99% времени.
Но вон телефония уже научилась сама стучать по событиям и это конечно кошерно.
Вот и с вьюхами бы так - пусть оно само там определяет, когда надо пересоздать, и пересоздает. Это ты про триггеры и имел в виду наверное?

(148) Ну да можно тригер повесить на изменение, но что этот тригер будет запускать? Нам же по идее надо вызвать 1С и выполнить в ней алгоритм перегенерации вьюх.

(149) Вот в примере выше с телефонией АТС умеет дергать ХТТП-сервис инфобазы 1С. В скуле бы так )

(148) Из тригера стучаться по Com к 1С, это жесть полная.  Хотя как я знаю есть один любитель делать обмены на тригерах, он даже статью на инфостарте вроде писал по этому поводу.

Не, СОМ конечно же не надо

(34) "А так же за любые последствия (явные и неявные), связанные с нарушением лицензионного соглашения 1С"

Ты думаешь что таким способом ты снимешь ответственность?
Сильно сомневаюсь. Только подтвердишь что при реализации нарушается лицензионное соглашение. От потенциального суда это не спасет. Или расчет что заказчик откажется?

(150) А почему нет? Вообще в принципе запросы на опрос таблиц на изменение с определенной периодичностью плохим тоном не считается. Так в принципе многие делают, чтобы триггеры не юзать.

(0) как всегда всё не читал,
у нас HTTP сервисы нам шлют запрос JSON в нем в обратку шлём,аналогично и мы забираем чрез api сервера.При этом не надо заморачиваться о внутреннем устройстве стороннего ПО и его БД.
это наиболее правильный и современный способ взаимодействовать между двумя по, ну еще более правильно сервис очереди организовать, но для нас это излишне.

(154) 1C тоже так делает :))
и дело тут даже не в триггерах

(153) Лицензионное соглашение от 1С противоретичит законодательству РФ в области правобладания. Единственное, что нельзя по нашему законодательству делать, это увеличивать количество пользователей, а так после покупки ПО ты можешь модернизировать его как хочешь. И по этому не было ни одного прецедента, по преследованию со стороны 1С таких случаев. На Хабре это лицензионное соглашение разбиралось по косточкам.
Суть соглашения, если ты полез напрямую, то 1С от тебя отмораживается, вот и вся его суть.

(156) Да хотел написать, что и 1С так делает.))))
Вообще наоборот использование триггеров является плохим тоном в разработке БД.

(158) @использование триггеров является плохим тоном в разработке БД@

Откуда дровишки?

(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

(159) Ну и как бы уже 15 лет с MSSQL это почти как аксиома.

(158) Ну, злоупотреблять конечно не стоит. Если в прикладной системе есть нужные события - то пользуемся ими. Но иной раз триггеры - единственно возможный выход. Делал как-то двусторонний обмен с польской программой для расчета окон, так пара триггеров и табличек-очередей решили вопрос. И куча вьюх, да. Поляки потом перенимать опыт приезжали :)
Или например формирование всяких вспомогательных табличек, протоколы там всякие - самый надёжный метод.

(162) Скажем так, если можно обойтись без триггера то его задействовать не стоит.
А так да, в момент моей молодости много чего под 77 на триггерах делал. Потом отучился.

С триггерами есть некоторая проблема в оптимизации запросов и пакетном добавлении,когда sql сервер не знает,что будет выполняться в триггере и быстрое добавление в таблицу может обернуться тормозами и блокировками.
Если триггер никуда,кроме самой записи не пишет,то таких проблем нет,но и отслеживание таким триггером не сделаешь.

(0) Я не пойму - а чем тебе не нравиться, что они что-то там забирают из базы SQL напрямую? Это нормально... Они же туда ничего не пишут, правильно? Их внешняя система - это их зона ответственности, пусть забирают то, что нужно и сами там разбираются. Тебе то какая разница? Ты просто предупреди их, что с обновлением релиза может измениться структура и наборы таблиц и все, дальше пусть сами.

(0) А если не хочешь их в базу пускать - тогда да, сделай или веб-сервис, или буферную базу/таблицу в sql, куда сливай нужные им данные, а они пусть забирают.

По поводу же минусов прямых запросов - их нет. Прямой запрос сработает значительно быстрее написанного на языке запросов 1с. Единственное что - тебе придется самому собирать нужные данные из всей этой мошны 1с-ных таблиц. Но это трудно только в первый раз)))

(167) [Прямой запрос сработает значительно быстрее написанного на языке запросов 1с.]

Можно подумать, запросы из 1С шлют не прямые запросы на скл - через прослойку сервера, но точно не о каком "значительно" речи не идет.

(0) если есть прямая доступность от получателя до скл базы, то вполне можно напрямую, почему нет. вьюхи (приведенные к человеческим именам метаданных) хороший способ. Аргументы про то, что структура меняется и "шеф все пропало" несерьезные - даже если не автоматизировать переформирование вьюх по актуальной структуре хранения, то частота с которой возникает изменение имен хранения делает ту проблему ничтожной.

(168) Прямой запрос в SSMS будет быстрее, чем где бы то ни было. -)
Впринципе можно отказаться от пользовательского интерфейса, все делать на sql скриптах.

(170) можно вообще от 1С отказаться, зачем лишние проклдадки в достижении результата

(168) Ну... это можете втирать тем, кто не видел ЧТО сервер шлет в запросах.

(169) "даже если не автоматизировать переформирование вьюх ...  то частота с которой возникает изменение имен хранения делает ту проблему ничтожной" // Как лихо ты отнес недоступность сервиса для потребителя к ничтожной проблеме, однако...

(0) "У клиентов периодически возникает потребность забирать данные из 1С в какую-то другую внешнюю систему (OLAP и т. д.). "

Для этого есть Automation

(167) Нет там никакого быстрее,если не извращаешся с кучей точек в соединениях и виртуальными таблицами в соединениях. Работают с точно такой же скоростью. Это если запросы одинаковые по подходу в написании. А вот когда начинаешь использовать всякие плюхи в виде великого и могучего T-SQL, ну типа CTE для замены в ИЕРАРХИИ() или для того же разузлования. Запросы к JSON, OPENROWSET, For XML, CLR, самописные функции в запросах, кореллированные подзапросы (1С умеет их только в секции WHERE) , да те же строковые функции TSQL. Тогда да, работает действительно быстрее. И операции модификации таблиц, вот это точно намного быстрее, т.к. 1С умеет только в построчную модификацию.

(102) (175) а можешь показать какой-то конкретный пример как делать вьюхи из 1с?
или пни меня, плз, в нужном направлении, типа гайда "как создать вьюху для чайников")

(176) Из 1С просто запускается запрос к СУБД, в справке к create view все описано

(176) ПолучитьСтруктуруХраненияБД(,Истина)
потом генерируешь текст вьюх и через ADO их создаешь.

(176)
Если захочешь использовать точки в таких конструкциях типа Справочник.Номенклатура, обрамляй их []

(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( ), но и эта функция у меня есть.

(176) и не забудь про перечисления, для них у меня отдельная таблица, вьюхь на них лучше не вешать т.к. будет множество юнионов по количеству перечеслений (каждое перечисление в отдельной таблице) и оптимизатор это запрос не сможет правильно обработать, ну либо материализуй такую вьюху.

(177) (181) спасибо, почитаю

Здравствуйте!
Сижу в Sql с таблицами с 1 с
Нужно найти в них факты продаж
c kakimi tablicami luchwe rabotat'?

(183) это очевидно... с продажными

(183) Если УТ 10x или УПП, то можно использовать регистр накопления продажи.
Но понятие регистр в 1С это несколько таблиц, с которыми вам предстоит разобраться. Проще всего, через профайлер посмотреть как 1С строит запросы к этому регистру.

А кто-нибудь задумывался, если скажем понадобятся остатки из регистров накопления? Представляете какую страхотень придется городить? Тут уже вьюхи не помогут.

(186) дык профайлер никто не отменял
копипастишь изапрос из профайлера

(187) Потом выкидываешь получившийся ужос и пишешь нормально :)
Но на посмотреть как принципиально это работает, можно.

(186) Если речь об оперативных остатках, это простейший селект к таблице итогов с отборами по дате(5999-11-01) и по складам-товарам, в соответствии с бизнес логикой. Сложнее с получением остатков "на дату", но и там не сложно - суммируется 2 выборки - ближайшие итоги и обороты за дельту дат.

(186) давно задумались . еще создатели 1с++ . запрос простой с учетом , что из итогов можно и вычитать .

(189) дадада, еще характеристики, серийный учет и прочая развесистость

(0)Главный минус, это то, что надо знать структуру таблиц и колонок. Если знаешь, то почему бы и нет. Но лучше конечно через родной механизм 1с.

(192) парсите конфиг , через dbnames сопоставляете имена полей и таблиц, храните сопоставление , далее парсите и сопоставляете в триггере только при изменении config .
изредка 1с меняет структуру хранения данных , как с константами.

(191) Это вопрос к перечню полей в group by, не более.

(0) кроме минусов есть и плюсы, можно READ UNCOMMITTED зарядить, указать в хинтах maxdop и т.п.
так что если 1С-кам жить не мешают, то вам то что
тем более если что работать не будет, сразу на них свалите )))