Доброго времени суток!

Есть две базы mssql и mysql c данными о событиях которые могут происходить каждую минуту/сек, попросили записывать эти данные в РС (данные нужны для отчета). Так как опыта пока мало с "внешних источников данных"... прошу совета у опытных...
Вопрос: Как лучше реализовать? Если данные нужны для только отчета, то написать запрос к двум базам и выбрать нужные данные(но настаивают пока, что должен быть промежуточный источник данных в РС), а если написать процедуру заполнения данных РС из внешних источников и пульнуть его в регламентные с частотой 1мин, то не повесит ли это базу в будущем?

(0) > то не повесит ли это базу в будущем
Если аккуратно все сделать, то не повесит.

При построении отчета внешними испточниками из двух баз, если одна из внешних баз не будет работать в момент формирования отчета, то у тебя не будет всего отчета. Ваш К.О. =)

Не повесит.

(0) 1. почитай про триггеры
2. пишется "внешняя приблуда", которая мониторит внешние базы и "сообщает в 1С"
3. как "сообщать в 1С" надо думать, имхо если sql база 1С то на сервере в фоновом дергать апи "внешней приблуды"

Если события имеют временные метки, то триггеры не нужны.

(3)+ 4. "внешняя приблуда" может быть написана и на 1С, но не в той же конфе/базе а отдельная внешняя

(1) (2) Хорошо, я тоже думаю, что не должно, но мало-ли я упустил какой нюанс)

(5) Почему?

(3) Хм "Будем посмотреть" © Гоблин, спасибо

(0) Пиши прямо на сиквеле, по триггеру :)

(0) Что за данные?
Какой объем изменения данных, распиши (База 1, и База 2)
Какая база где у тебя вертится? (Типо Одна в Московии, другая во Владивостоке, на Пне 386)

Чем больше пишешь ответов, информации, тем нам легче тебя подтолкнуть...

+ Что за конфигурации, обоих баз?

...Продолжай, писать... мы смотрим... :)

+(0)Как вариант, можно писать вообще в БАЗУ МЕЖДУ (Промежуточную, которая будет содержать ответы для отчета)
И подтягивать данные через прямой запрос, или внешний источник.

+ База на сиквеле со своей структурой, не от 1С :)

(10) Ну да одна в Московии другая СПб, Конфа самописка на УФ, Данные СКУД...

(12) Не, не вариант...

(14) СКУД вообще как-то не вижу особого смысла "засасывать"... Нафига зеркалировать этот мусор?

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

(14) Производительность разве что...
Ну, СКУД в РС можно без проблем хоть каждую минуту "подсасывать". Только установку соединения лучше делать через модуль с повторным использованием возвращаемых значений (чтобы переиспользовать, а не каждый раз новое).
(17) Не нужен тебе триггер.

(16) Я тоже не вижу смысла раздувать базу мусором, тем более для отчета, но вот хочется им...

(17) Просто фиксируй, по какой момент времени загружены данные с прошлого сеанса обмена и все. Только ессно время последней загруженной записи, а не локальное время.
(19) В принципе, ничего страшного. Можно чистить периодически.

(14) СКУД у вас на чем вертится?

(20) Понял, спасибо буду разгребать)

(21) один mssql другой на mysql

(23) Если только в МайСКуЛь дописать таблички:
   1. - Для накопления приходов
   2. - Для Сброса в офис во Московию

1. Таблицу № 1 пишем, как только сотрудник пришел.
2. Таблицу № 2 пишем, как только Таблица № 2 оказалась пустой.

В итоге ты всегда будешь работать с таблицей № 2... Забирать от туда данные и удалять их после забора, что бы туда прописался следующий поток "Сознания" :)

+(24) Таблица № 2, заполняется данными из Таблицы № 1, и соответственно, при заполнении Таблицы № 2, таблица № 1 очищается :)

(24) Дык а заполнять табличку по триггерам же.

Появилась запись о считывании карты сотрудника - херак и всех сотрудников сегодня чьи карты считались пишем в другую табличку с датой.
И пофиг что она перезаполняться будет при любом считывании

(26)+ Причем если добавить время и то можно получить время прихода и ухода в конце

(24) > Таблица № 2, заполняется данными из Таблицы № 1

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