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

(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С-кам жить не мешают, то вам то что
тем более если что работать не будет, сразу на них свалите )))