Включение потабличного RecID в 3-ке

[ZVV]

Владислав, а Вы не можете сказать, раз у Вас есть такой опят, как такое решение сказывается на производительности системы?
Если оно как-то сказывается?

PS Например если "выкинуть" таким образом InventTrans.

[Vladyslav]

Опыт есть, но не InventTrans
Как я уже упоминал: был заказ протоколировать всякую хрень, и объем этого протоколирования угрожал за впрочем довольно долгое время, но все же "съесть" весь ресурс идентификаторов записей.
Может если "выкинуть" подобное, то и для InventTrans хватит оставшихся двух миллиардов (это не считая отрицательных значений)?
Падения производительности не заметил (да и к чему бы). Будет ли падение при обращении к InventTrans? Вряд ли. Аксапта ведь в SQL запрос с объединением передает не как a.dataareaId = 'my1' and a.dataareaId = b.dataareaId, а как a.dataareaId = 'my1' and b.dataareaId = 'my1'
Нет, ну разумеется она там где-то внутри себя потратит время на "подстановку", но столь малой (надеюсь на это) величиной можно пренебречь

[ZVV]

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

Резюме: Пользуйтесь поиском, не изобретайте велики!

[Vladyslav]

Ну вот "наобещал" и сегодня же (впервые) нарвался на место, где 3-ка предполагает уникальность RecId в пределах всей базы: таблица SpecTrans
Поле RefId было заменено в четверке на RefTableId и RefRecId
Просто если пометить открытые проводки для сопоставления клиентские (CustTransOpen), то можно при наличии "своих" RecId в открытых проводках поставщика (VendTransOpen) доооолго размышлять, чего это она считает, что проводка еще где-то помечена.