Приветствую господа!

Как мы знаем - Ключи аналитики просто справочник.
Информация о нём - в Соответствующих регистрах.
Имеем РИБ, много узлов.

Ситуация - в разных узлах в производство списывают Доски, первый раз в жизни базы.
Ключа такого нет, он формируется новый. В обоих базах свой ключ, но одинаковый по сути.
Идут обмены, в итоге запись в регистре есть только об ОДНОМ ключе, а в движениях РАУЗа 2 ключа

Если ещё раз списать доски в узле - подхватит ключ о котором есть запись в регистре, т.е. второй ключ.
Имеем в РАУЗ 2 записи одинаковые по смыслу (и визуально одинаковые), но с разными ключами.

Если перед расчетом себестоимости провести все доки - всё выровняется, но это просто нереально на больших объёмах, причем собственно и одно из достоинств РАУЗа - не надо ничего перепроводить
Обработка ТИИ ключей - не исправляет данную ситуацию.

Кто думал о такой ситуации вобще? Как бороться по феншую чтоб?

Найти такие записи в Учете затрат легко, но надо делать замену ссылок, ибо в РС нельзя запихнуть информацию о 2-х одинаковых ключах...

сделать дополнительный оперативный обмен ключами

(2) да, риск снизится, но таки возможна эта ситуация, если реально в одно время будут проводить. Предполагаем сделать 5-ти минутный обмен ключами и РС. Хочется 100% гарантии

(0) а РСВ делают параллельно во всех базах ?

В типовых, для ключей, есть собственное ТИИ :)

Тестирование и исправление ключей аналитики тебе поможет.

(5) писал в (0), ТИИ ключей не исправляет данную "коллизию"
(4) сейчас - нет, идёт обкатка на 3-4 узлах, закрывают прошлые периоды

(6) нет, смотрел что она делает то?

(7) + но уже столкнулись

(7) ещё раз:
определись с главным - где будет РСВ

ТИИ ключей:
1. удаляет лишние (нет движений по этим ключам)
2. правит наименование ключей
3. удаляет и заменяет битые ссылки в движения РАУЗ

(6) Нет, не поможет. Не всегда. Но туда, в отличие от ТиИ - можно внести изменения.

(8) Проверяет корректность, ищет и удаляет дубликаты, удаляет неактуальныеключи.

(10) РСВ будет в каждом узле запускатся, узлов много, всё делать в центральной - не вариант. 15 узлов

(0) решение только одно. Формировать гуид ключа по md5. Тогда всега будет один ключ на всех узлах.

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

(14) хм, оригинальный вариант

(14) после этого можно будет отказаться от рс

(17) как отказатся? инфа о ключах в РС, это не КА, где в справочнике реквизиты есть

(13) Так не стоит делать. Себестоимость нужно считать в одном месте - это вопрос не политический или экономический - это чисто технический.

У меня случай, имхо, хуже: себестоимость по УУ - в одном узле, по БУ - в другом.

(11) Ну допиши обработку, добавь в функционал удаление дублей с заменой ссылок...

В ключе есть реквизиты со значениями . Рс для уникальности

(13)[РСВ будет в каждом узле запускатся]
у тебя 15 юрлиц  или ты не понимаешь, что РСВ при РАУЗ делает половину проводок НУ ?

(19) ладно сст, а когда движения по продажам идут с ключами

Bober, без обид, ты не прав. Тебя юзверы повесят за одно место, когда увидят отчеты в РАУЗе с твоими гуидами.

(20) вот собсно и сделал ветку чтоб решить что лучше. вариант (2) рассматривается, и твой в данный момент
(21) в УПП нет реквизитов
(19) да боюсь нереально, 15 РСВ делать в центре (причем же править как обычно надо, с первого раза расчитывается правильно только в сказках
(22) Холдинг, 15 Организаций именно, потом всё консолидируется (ну Центр узел можно считать уже консолидированой базой)

Да, узлы независимы в учете, разные организации. Справочники едины для всего холдинга

(25) Погоди, так а чем тебе задвоенные ключи жить помешали-то?

(27) мешают жить в случае:
>>Если ещё раз списать доски в узле - подхватит ключ о котором есть запись в регистре, т.е. второй ключ. Имеем в РАУЗ 2 записи одинаковые по смыслу (и визуально одинаковые), но с разными ключами

визуально всё норм, а ключи разные в одном узле

+ на один из этих ключей нет записей в РС

(25)[15 Организаций именно,]
а нафига тогда вести учет в одной базе,  а не в 15 ?

(30)+1

(30) Прикалываешься или действительно так считаешь/не понимаешь?

(30) учет в разных.
РИБ сделана для:
Общие справочники (номенклатура, контрагенты, договора и т.д.)
Вся инфа с организаций сливается в одну базу Центральную (считай сразу консолидация на будущее)
Внутренние взаиморасчеты всякие хитрые и т.д.

(27) может непонятно объяснил, давай проще - Документ должен при перепроведении делать такие же движения что и раньше, в данном случае старый док сделает другие движения (с другим ключем).
Учет затрат - остаточный, разные ключи разрывают остатки

Сам вроде склоняюсь к мнению что легче дописать ТИИ ключей, замену ссылок сделать опираясь на РС ключей. Но ученые коллеги внедренцы хотят спец обмен быстрый + потом туже замену ссылок ключей, но как то через опу

(34) Да всё понятно) В любом случае, как бы ты оперативно не обменивался ключами, будут задвоенные. Поэтому в любом случае нужно будет удалять задвоенные с переносом ссылок...

(36) такая хрень возникает только если в промежутках между обмена создаются новые ключи, и информация из РС не дошла ещё до узла где формируют новый. Не так часто это на самом деле, но таки есть

(25) (35) если пойдут доработки, то проще сделать как это сделали в УТ 11. у ключей реквизиты-аналитики + регистр сведений (борются с контролем уникальности, так как накладывать блокировки на спр по реквизитам нельзя).

итого: потребуется переделать запросы, которые тягают данные из РС, но это мелочи.

У меня риб-база (и те-же проблемы с ключами). Но: автор не совсем правильно "акценты" ставит. "Дубликаты" возникают не от того что РСВ по разным узлам делается, а потому, что любое движение по новой номенклатуре генерирует ключи "на лету" в момент проведения документа.

(39) я вроде на РСВ акцент не ставил вобще) в сабже токмо про документы, и как они формируют ключи)

(39) как борешся кстати?

(35) А как часто сейчас обмен идет?

1. оперобмен в 2-3 минуты
2. обработка исправления

И в методике устранения дубликатов несколько иная механика.

3. и письмо в 1с, пусть думают

>>потребуется переделать запросы, которые тягают данные из РС, но это мелочи
хм, при той же РСВ - запросы и к РС, а там переписывать нихрена не мелочи
(42) 4 часа, полный цикл Узел1 - Центр - Узел2 получается 8 часов

(45) проблема не нова, не думаю что будут что-то делать. или скажут что в УПП 1.3 всё реализовано
(44) какая? где она?

(46) Ну, терпимо. Я думаю, спец. обмен делать, пока, не надо - т.к. новая номенклатура летает только с текущими обменами и всех устраивает ведь... Значит и ключи не будут так сильно дублироваться, мне так кажется. Пока сделай удаление дублей в регламентном задании, ну а если функционала не хватит, то спец. обмен замутишь.

(38) из-за того, что в платформе не был встроенный метод получения md5, 1с не распространила ключи аналитики на все регистры учета, а ограничила только только упр регистрами, мол считать такие вещи нужно только в центральном узле.
После выхода 8.3 в типовых переделают на этот подход и мы еще увидим эти ключи аналитики во всех регистрах учета -)

PS когда переделаешь с рс на реквищиты, в отчетах заработает такая конструкция:
.Обороты(, {КлючАналтики.Номенклатура.* КАК Номенклатура})

(48) беда в том что номенклатурина летает каждые 5 минут специализированными средвами. аля общий репозитарий НСИ.
Заставлять юзеров ждать добавления в номенклатуру Гвоздя 4 часа - порвали бы на месте всех

Возникновение дубликатов ключей в риб-базах - не столь глобальная проблема, чтобы курочить внутренний механизм РАУЗа :(

(51) угу, вот и думаем как малой кровью

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

(52) плотной работы на три дня.

(51) не столь глобальная особенно когда регистр "не закрывается".

(50) Ну, раз так, то теми же специализированными средствами гоняй ключи туды-сюды))

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

(53) на получение аналитики через точку? имхо самый верный способ положить базу

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

(58) утром упал?

(57) Ф топку перепроводить весь документ! Надо просто сделать замену ссылок, имхо.

(58) прости, отвлек от утренней молитвы 1сника "никаких точек в запросах". Продолжайте, не будут отвлекать

(62) Оо уж0с, я так всегда делаю, это всё типовые виноваты!

Ну как понял таки проблема есть не у меня одного, 1с её не контролирует в типовых, выкручиватся самим

(64) так точно. Причем сценарий с заменой ключей по поиску еще более адовый

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

(64) кстати, ты говорил, что спр ключей нет реквизитов аналитики, тогда как понять какая аналитика у ключа, если он вылетел из рс при обмене?

(66) никак, по наименованию только...
т.е. таки надо будет перепроводить доки, в которых ключ не имеет записей в РС. Он подхватит правильный ключ, а этот удалять.
Ну или провести в транзакции - взять ключ, отменить транзакцию. Узнаем нужный ключ, заменим все неправильные на нужный

Сорри, отвлекли работой :)

"Надо просто сделать замену ссылок, имхо." - документы, увы надо перепровести. Можно только по одному регистру (что я и делаю). Там не только ключ при этом меняется - но и суммы плывут (другой ключ = другая аналитика).

(67) треш, у тебя какая упп?

(69) 1.2.27
З.ы. переходить на 1.3 не советовать)

1.2 или 1.3 - без разницы. Риб-база - это первично.

(33)[учет в разных.
РИБ сделана для:
Общие справочники (номенклатура, контрагенты, договора и т.д.)
Вся инфа с организаций сливается в одну базу Центральную (считай сразу консолидация на будущее)
Внутренние взаиморасчеты всякие хитрые и т.д.]
если РСВ делается в периферийных базах, то пофиг дубли аналитик

отчетность по Рг РАУЗ в разрезе номенклатуры то будет верной

(72) проблема в (68) получается больше, может в рауз сумму неправильную кинуть, списание по средней, остатки в раузе будут не соответсвовать ключу... нет?
Однотипные документы будут делать разные движения, хотя визуально одинаковые

(73) у тебя аналитическая база, в ней нельзя перепроводить документы, а движения передаются из узлов - я правильно понял ?

если это так, то какая разница сколько записей в справочнике аналитика учета затрат, ты же отчеты по РАУЗ для конечных пользователей строишь в разрезе номенклатуры ?

(74) +1
иными словами для консолидации уровень аналитик учета РАУЗ не нужен

(74) давай пример напишу.
проводим док1 01.01.2012, списываем в производство Доску.
Ключ встаёт новый созданный в этом узле.
в другом узле сделали аналогичную операцию, тоже новый ключ.
после обменов ключа 2, а запись в РС одна.
Проводим док2, 02.01.2012, аналогичная операция.
Но ключ он подтянет который в РС, а это не тот, по которому сделал движение док1.
остатки в рауз будут какими? их порвёт разной аналитикой

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

Я непонимаю, зачем 15 заводов сливать в одну базу? Если нужна консолидация данных - есть специализированные продукты, нпрм 1С:Консолидация. Нужна общая НСИ, сделай базу (Портал) для только для учета НСИ и реплицируй как угодно часто с локальными базами.

(77) это сделано давно и не мной, изначально была заложена идея централизации. Есть бизнес процессы которые гуляют между узлами, много причин, я же борюсь с последствиями. Такая структура тоже имеет право на жизнь, не меньше чем 15 отдельных баз + консолидация, просто тут подводный камень типа этого обнаружился

(76)
(77)
значит я не прав
лет 5 с РИБ не работал

shuhard, проблема в том что при повторном проведении документа ключи аналитики могут "самопроизвольно" измениться. Ладно если только суммы плывут, но аналитики... Дубли аналитик --> в отчетах - каша --> юзверы в непонятках = вопросов больше, чем ответов :(

(78) решение ты уже знаешь, осталось только решиться это сделать.

(81) решений много, надо выбрать)

(82) оно одно, все остальное полумеры

(83) уволится?)

(80) верю (с)

и решение ТС-у надо искать архитектурное

возможно не передавать Рг РАУЗ в центр совсем

и узнать это можно только из целей консолидации

На существующих типовых объектах УПП вряд ли что-то получится.  Как вариант: отключить обмен справочниками Ключи аналитик и регистрами Аналитики учета. В переферии перед обменом изменившиеся Ключи аналитики сливать в дубль-справочник, значения регистров Аналитик в дубль-регистры. Закачиваем дубль-справочники и дубль-регистры в центр, после отого запускаем постобработку по соединению справочников и регистров в типовые справочники Ключи аналитик и типовые регистры Аналитик учета.

(85) в систему заложен постулат что не должно быть разницы между узлами и данными в центре, т.е. проведение дока в центре должно благополучно отразится и на узле, поведение системы должно быть одинаково в рамках всех узлов РИБа

(84) это полумера. передай получение ключа на md5 и все. можно даже оставить эти грабли с РС. Главное, чтобы гиуд ключа (ссылка на объект) в любой точке была одинаковой.

(88) передай -> переделай

(88) да, интересная идея, буду брать в расчет

>>проведение дока в центре должно благополучно отразится и на >>узле
писец

(88) а одинаковой она может быть толко с хеш-функцией и все.

(91) почему?

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

Даже если сотня узлов одновременно сделает этот ключ, он все равно будет одинаковый.

Как будешь отрабатывать ситуацию по одновременному проведению дока по одинаковым аналитикам в центре и на переферии?

(70) к сожалению не нашел в закромах такой старый релиз. Но по описанию уже и так понял как это сделано в этой редакции.

(про себя, молча) А ведь истиную проблему возникновения дублирования ключей так и не озвучили. Если убрать все наслоения - то имеем классическое "Хаос невозможно автоматизировать"(с) Решение - административное.

(95) РИБ делаёт это за нас, т.е. вариант центра при обмене будет истинный.
Это не значит что в центре сидим проводим за всех, просто есть такая возможность

(94) да, я оценил уже подход

100

(97) решение на уровне платформы а не административное.
Так как дубли ключей могут появиться, если одновременно провести два документа с отсутствующими ключами с системе.

(99) теперь когда ты оценил, ты понимаешь что все остальное это просто полумера.

(97) какое именно? на примере (76) не вижу административного решения...

(103) добавлю, что на больших базах специально выносят упр. расчеты на отдельный узелю

(102) две полумеры ведут к гарантии, т.е. 1.быстрые обмены + 2. замена ссылок. Но делать конечно геморней

(105) оцени доработки двух костей и их последующее администрирование.

(105) особенно в части замени. так как после замены потребуется перерасчет.

В любом случае перепроведение открытого периода перед РСВ мне кажется полезным.

(106) хм, MD5 получается сразу подходит для генерации ссылки по гуиду?

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

(110) уже проверил?

(111) нет, пока умозаключения, ибо мы делаем свой порядок генерации ссылки. Кто гарантирует что такой уже нет? МД5 как раз подходит для гуида, 32 символа в виде 16-чном.

(112) тьфу, т.е. не подходит немного)

(113) и что не подходит?

затронута похожая тема

http://partners.v8.1c.ru/forum/thread.jsp?id=1089379

ответ 1с:
Мы рассматривали такую идею в самом начале, но нам не удалось найти приемлемого решения. Преобразование гуидов по математическим формулам не может дать 100% гуид.

(116) у кого доступа нет - ответ был на вопрос:

а не хотите-ли вы генерировать гуид ключа на основании значений ключа
например: гуид партнера + гиуд организации + гуид контрагента - md5 = гуид ключа.
тогда можно будет и в РИБе это использовать.
(с)

правда я сам не понял пока почему мы не получим 100% гуид.

хотя может и понял...

Если у двух строк хеш-коды разные, строки гарантированно различаются, если одинаковые — строки, вероятно, совпадают. (с) вики

т.е. одинаковый

(119) + одинаковый хэш-код возможен у разных входных данных

а вот и Bober пришёл)
на партнёрке тоже обсуждали, йс отказалась от идеи короче, хоть и красиво, но не 100%

(121) не знаю, почему отказались, делал. работает.

(122) работать будет, но нет гарантии просто. Теоретически возможна бяка, когда один гуид сгенерится на разные данные

(120) да, такое возможно, но вероятность маленькая. Еще как вариант написать свою хеш-фукнцию и спасть спокойно.

а 1с ничего не делает, если нет 100% уверенности, допущений не допускают, и делают по своему через опу

(123) зато сейчас гарантий полно -)

(125) делает, поэтому мы и обсуждаем как это переделать.

(126) ну разгребать овно в РИБе они разрешают самим...

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

(129) короче великие наши внедренцы последовали совету 1с так не делать. будем мучатся с комплексом затычек: быстрые обмены, замена ссылок, перепроведение

вот как делал MD5(НРЕГ(СтрЗаменить(XMLСтрока(Ключ.знч1) + XMLСтрока(Ключ.знч2) + XMLСтрока(Ключ.знч3)), "-", "")). Далее все это в ссылку. Полет нормальный.

PS
- Если значение ключа составной тип, то обязательно добавлять  гуид тип объекта и следить за тем, чтобы значение было
заполнено.
- если значение ключа пустое, то все рано передавать гуид (00000000-0000-0000-000000000000).
- если количество аналитики меняется, то потребуется все переделывать.

(131) можешь поделится функцией MD5? для себя

(132)
http://infostart.ru/public/96713/

(133) это видел) я имею ввиду использовал читсый алгоритм этот, без дополнительных доработок?

с генерацией ключа?

(135) для генерации гуида

(136) + тупой вопрос, дефисы вставить только)

(137) нужно подождать, сейчас пример сделаю.

(137) тебе всю мини конфу или только кусок кода?

(137) накатал пример

ТекстДляКлюча = НРег(СтрЗаменить(XMLСтрока(Объект.Номенклатура) + XMLСтрока(Объект.Характеристика) + XMLСтрока(Объект.Склад), "-", ""));
   ХешТекста = ОбработкаОбъект.MD5(ТекстДляКлюча);
   
   ГуидТекст = Сред(ХешТекста, 1, 8) + "-" + Сред(ХешТекста, 9, 4) + "-" + Сред(ХешТекста, 13, 4) + "-" + Сред(ХешТекста, 17, 4) + "-" + Сред(ХешТекста, 21, 12);
   Объект.КлючАналитики = XMLЗначение(Тип("СправочникСсылка.КлючАналитики"), ГуидТекст);
   
   //идет в транзакции для блокировки спр
   НачатьТранзакцию();
   ЗаблокироватьСправочникПоСсылке(Объект.КлючАналитики);
   Если Не КлючСоздан(Объект.КлючАналитики) Тогда
       СоздатьКлючАналитики(Объект.КлючАналитики, Объект.Номенклатура, Объект.Характеристика, Объект.Склад);
   КонецЕсли;
   
   ЗафиксироватьТранзакцию();

(140) мини конфу на мыло можно, если не трудно)
впринципе понятно конечно

Я не тупой или упрямый, я - упорный :)

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

(142) всмысле? какой пример?

ТС, как тебе идея: генерировать заранее набор ключей, при добавлении новой номенклатуры в справочник?

(142) пример - АналитикаУчетаЗатрат, там запросто

(144) тоже как вариант, только ТИИ ключей убъёт их, ибо они не используются

(145) Для новой номенклатуры ключ создаётся при первом поступлении(оприходовании) в организацию. Как ключ ухитряется дублироваться? Вы сразу на нескольких узлах поступление(оприходование) вбиваете?

(146) Запуск ТиИ ключей можно зарегламентировать - запускать не тогда, когда хочется, а тогда - когда можно :)
  В алгоритм можно внести условия(ограничения) по удалению неиспользуемых ключей.

(141)

http://rusfolder.com/33871746

(147) номенклатура - там десятки тыщ наименований. заветси её могут давно заранее, когда запланируют

(148) спс. заценю на днях

(142) (147) детсад какой-то.

(147) убрать эту функцию из обработки можно конечно... но, как ты себе это представляешь? на ВСЕ сочетания номенклатур, характеристик, статей, серий, качество и т.д. создавать ключи? боюсь распухнет справочник до неприличных размеров

У меня, наверное, какая-то неправильная УПП: для позиции номенклатуры пара-тройка записей, ну максимум 5-6 в аналитике учета затрат.

(153) это не все варианты, а те которые ты используешь... ты предлагал все варианты создать, ибо кто значет что введут и какой ключ понадобится

Вообще-то я имел ввиду, говоря про "набор", что это не всевозможные варианты. Например: "набор" основные производственные материалы. Статья затрат - определена и не изменяется. Качество - новое или брак (допустим). Пришло на склад - ушло в производство. Всё.

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

Ладно, уговорил. Не универсальное решение.

Другая идея: специально выделенный план обмена только по этим справочникам и регистрам. Обмен по событию (по мере надобности - по факту добавления новой записи в справочник). Как тебе это?

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

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

(158) самое смешное что это фпнач-внедренец у нас делает, т.е. ему лишь бы сделать, кто поддерживать будет - не их проблема

*франч

(161) бррррр. звери а не люди

(159) Ну, в принципе... новая запись справочника может быть только "спусковым курком" - сам обмен начнется через несколько секунд допустим. Одна или куча записей туда войдет уже не важно. Тот кто не успеет - вновь взведет курок.

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

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

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

Я в курсе. Всё дело в вероятности. Точнее - насколько она низкая :)

Между прочим: если новый ключ обменом будет распространяться, скажем, за пять-десять секунд - то можно, имхо, обойтись без прочих костылей. А такая скорость обмена - вполне реальна.

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

делают костыли чтоб была гарантия 100%. хз чо у них получится

(168) если генерить другой - то по какому алгоритму? и другая база должна знать что ты в узле1 сменил алгоритм

(170) посмотри, сколько сейчас ключей в базе

(171) каких именно? затрат?

Всех различных

Ключи аналитики вида учета    10 136
Ключи аналитики распределения затрат    4 705
Ключи аналитики учета затрат    170 868
Ключи аналитики учета партий    71 211
Ключи аналитики учета прочих затрат    2 541

такая петрушка

Группа риска как раз "Ключи аналитики учета затрат"

(170) Если есть один, общий для всех, генератор - почему бы у него не может быть другого, запасного алгоритма - тоже общего для всех? :)

Не нужно второй базе "знать" об этом. Предположим в первой базе уникальное наименования порождает неуникальный ключ - будет генерится другой ключ. Во второй базе, в аналогичной ситуации - тоже будет гериться ключ по запосному алгоритму.

(176) Это если обмен уже прошёл. А если между обменами создадим элемент1 и при попытке создать 2-й - токая же ссылка - то вернёмся к (0) :)

это всё на самом деле ОЧЕНЬ маловероятно. и легче сделать один из вариантов, чем пытаться делать АБОСЛЮТНО гарантированную систему

(177) Не согласен. Вероятность повторной генерации - очень низкая(но есть). А повторной генерации номеров в период между обменами - стремится к 0.000(0)

(179) дак и по MD5 - стремится к 0 вероятность... но возможно :(

Возможно? "Будь мужиком"(с) - сделай так и докажи обратное :)

я - афк, бб.

(181) теоретически возможно. опровергать логику я не научился