Прошу Вашего совета относительно следующего случая.
Имеется несколько баз SQL Server с одинаковой структурой. Связи между ними, к сожалению, никакой нет. Но зато есть необходимость объединения накопленных данных в одной базе. Все бы ничего, если бы не ключевые поля. Ведь при объединении возникнет вероятность совпадения ключевых полей некоторых документов из раличных баз.
Конечно, можно ввести составной ключ, который бы исключал всякую возможность совпадения ключей, либо задать правила формирования ключей для каждой из удаленных баз данных. Но может быть я что-то упустил из своих выкладок и существует более красивое и менее рискованное решение?

Спасибо, коллеги. Сразу видно, что данный вопрос в свое время затронул каждого из вас. Ну вот дошла очередь и до меня... Мне уже не раз предоставлялась возможность оценить крайне полезное сочетание: выделенная линия в Инете + эта классная конференция Вы помогли мне избежать многих глупостей.
Для себя я решил воспользоваться советом Alexander Chepack и ввести идентификатор сервера. Хорошо, когда ключ несет в себе какую-то смысловую нагрузку, а не является просто нагромождением цифр В большинстве случаев я использую составные ключи. На данный момент они будут включать в себя:
1) поле со сквозным накоплением значений в пределах организации и сервера,
2) поле идентификатора организации,
3) поле идентификатора сервера.
Быть может, это не разрешит всех моих проблем. Если это так, пожалуйста, подскажите!

2 Genady
Данную статью, а также весьма эмоциональное ее обсуждение на этой конференции, я читал можно сказать "в режиме реального времени" Моя задача включает только те условия, которые я перечислил и, по-моему, в рамках вышеописанной конструкции составного ключа она решается. Если нет, подскажите, почему? Перелопачивать же все свои базы на предмет замены ключевых полей мне бы очень не хотелось..

2 Garya
Дело говорите. Если не трудно, можно поподробнее? Не обязательно прямо сейчас. Сегодня я отчаливаю из нашей столицы-матушки, но к понедельнику думаю вернуться
Тема модификации записей и их приема-передачи также очень волнует меня. То решение, которое пока реализовано у нас, берет на свои широкие плечи Access2000 Сами можете судить о гибкости, тормознутости, надежности и удобстве такого решения. В недалеком будущем я буду вводить другое решение для проверки его на эффективность. В нем я использую поле идентификатора измененной записи, т.е. данное поле накапливает в себе значения после каждого изменения записи. В общей базе поля просто сравниваюся. Ситуация "одни и те же данные изменяются одновременно на нескольких разных серверах" исключена. Но сделать решение на вырост, если это мне по зубам, все равно интересно. Жду Вашего ответа.
PS. Мой адрес: alexandr_k@baucraft.ru

2 Garya
Спасибо за ответ. Принцип мне понятен. Похожую схему я реализовывал на одном авиационном заводе. Там на различных участках учета очень любили плодить информацию, переделывать строки дебета и кредита при уже рассчитанном сальдо, при этом часто забывали пересчитать его заново, иногда исправляли и само сальдо, что очень украшало оборотно-сальдовую ведомость Почти полгода у меня ушло на то, чтобы врубиться в местную форму учета(все это время генеральный конструктор АСУ принуждал меня к изучению Кобола и обслуживанию большой ЭВМ - и это в конце 90-х!), но самое трудное было еще впереди Именно там я впервые задумался о том, что физически удаленных записей быть не должно, каждая запись должна иметь дату ее создания и идентификатор создателя, по истечение определенного времени записи на сервере вообще не должны давать себя корректировать без особого разрешения и т.д.
Представляете, все это делалось средствами Access97 в ЛВС на коаксиальном кабеле и работает до сих пор спустя полгода после моего ухода! Сразу скажу, что для этого завода даже Access был большим прогрессом, а также такой нервной перегрузкой для большого начальства, что в конце концов мне пришлось подать заявление об уходе..
Если Вы не против, я воспользуюсь некоторыми Вашими выкладками.. Был бы очень рад увидеть Ваши новые статьи.
Успехов. Александр.

2 Garya

Спасибо.