Добрый день !
Всем спасибо за помощь. Решил воспользоваться вашими рекомендациями и организовать обмен между 1С и MSSQL с помощью плана обмена и соответственно выгружать изменения в SQL - ю базу. В связи с этим возникло 2 вопроса:

1. Для обеспечения целостности данных возникла необходимость выгружать не только сами рабочие данные, но и внутренние идентификаторы (UID) объектов 1С. Вопрос в следующем - какой тип данных назначить для UID в SQL - й базе ? Достаточно ли назначить тип данных char(36) (для всех справочников метод УникальныйИдентификатор() выдает идентификатор разрядностью 36 символов) или все-таки это не гарантирует корректность данных и необходимо преобразовывать char в binary(16), т.к. именно в таком формате хранятся все uid-ы в SQL-м варианте 1С-х баз ?
2. Для обеспечения уникальности данных по uid необходимо ли назначать данное поле в качестве ключевого ? С точки зрения производительности лучше всего суррогатные ключи, само собой, но как тогда быть с механизмом обеспечения уникальности uid-ов ? Организовывать проверку с помощью триггеров ?
Всем заранее спасибо !

Это необходимо для обеспечения ссылочной целостности - я выгружаю информацию в связанные таблицы - грубо говоря, несколько справочников, а также документов, реквизитами которых и являются выгружаемые элементы справочников. Элементы справочников и документов могут быть удалены, а на этапе анализа изменений из плана обмена я могу отслеживать такие объекты только по UID. Кроме того, коды справочников и документов могут также изменяться, соответственно, коды нельзя будет использовать в качестве ключевых полей. По моему мнению, UID - самый идеальный вариант в данном случае.

Вопрос еще актуален. Неужели никто не сталкивался с подобными вопросами при решении аналогичных задач ?

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

Спасибо всем за полезно-бесполезные советы !!!

VladimirKrПоследний выдох ГПЖ>Организуйте транзитную БД на SQL сервере, создайте там необходимые view с вменяемыми названиями полей, необходимые таблицы связи ваших не1С-ных сущностей с объектами 1С и вперед.

при частых обновлениях связи будут рассыпаться...
Любые связи рассыпаются при частых обновлениях. В том числе правила обмена, но частые обновления структуры данных заканчиваются вместе с разработкой конфигурации и началом нормальной эксплуатации.

автор да и выковыривать данные из полей составного типа - удовольствие ниже среднего

Создание/пересоздание view, основанных на несущих таблицах 1С легко автоматизировать.

Учитывая, что моем случае база 1С постоянно дорабатывается несколькими программистами, в т.ч. из удаленных филиалов, расположенных в других часовых полюсах, мне придется отложить решение остальных задач и регулярно, 24 часа в сутки только и заниматься, что пересоздавать вьюхи.

Я самостоятельно привык решать поставленные мне задачи - и на этом форуме я сижу не в поисках халявы, а в надежде получить советы по поводу тех или иных проблем, описанных более чем конкретно.

Я с самого начала указал, что база в файловом режиме - если бы была возможность перевода ее в sql вариант, я бы так и сделал с самого начала.

VladimirKrНу, раз не хватает денег или наглости перевести на SQL, тогда

автор1. Для обеспечения целостности данных возникла необходимость выгружать не только сами рабочие данные, но и внутренние идентификаторы (UID) объектов 1С. Вопрос в следующем - какой тип данных назначить для UID в SQL - й базе ? Достаточно ли назначить тип данных char(36) (для всех справочников метод УникальныйИдентификатор() выдает идентификатор разрядностью 36 символов) или все-таки это не гарантирует корректность данных и необходимо преобразовывать char в binary(16), т.к. именно в таком формате хранятся все uid-ы в SQL-м варианте 1С-х баз ?
Назначить лучше uniqueidentifier или binary(16). Но если есть трудности с преобразованиями то достаточно и char(36).
автор2. Для обеспечения уникальности данных по uid необходимо ли назначать данное поле в качестве ключевого ? С точки зрения производительности лучше всего суррогатные ключи, само собой, но как тогда быть с механизмом обеспечения уникальности uid-ов ? Организовывать проверку с помощью триггеров ?
Всем заранее спасибо !
Вы не ответили на вопрос выше: Собираетесь сами без 1С создавать 1С-объекты?

Нет, ввод информации в базу будет осуществляться исключительно средствами 1С, я планировал изначально использовать уникальные идентификаторы исключительно для обеспечения целостности.