Мне лично связка по RecId не очень нравится.
- Нет перехода к основной таблице (его надо делать, автоматически его нет).
- Неясное (ненаглядное) название полей и когда рыщещь обозревателем таблиц или что еще хуже - на уровне БД - тоскливо разбирать данные
+ Универсальность связки. Когда несколько исходных документов прилинковываются к одному журналу - это удобно.
- Перенос данных. Особенно - если это настройки. Все делабельно... но только на уровне Аксапты - т.е. уже минуя Аксапты это не сделаешь. А иногда (перенос между разработческой, тестовой и рабочей БД) - есть потребность перенести данные не заморачиваясь c RecId
- Опускание в слой. Если таблички свои - то при смене их ID нужно не забыть про уже созданные данные со ссылками по TableId.
В общем-то - это все так... личные предпочтения. Как было замечено выше - при правильном (по MS) подходе - все будет ок.
Но когда-то ранее уже всплывали темки типа а как перейти с SQL Server на Oracle, которые в принципе по MS-ному не делаются
. Но при желании делаются в жизни. Так и тут. Я лично предпочту по максимуму избежать связок по RecId именно в рамках облегчения администрирования.
Кстати. На одном из проектов - возникла необходимость код строки настроечной таблицы вставлять в транзакционную таблицу (ну это тоже самое, что в бух проводки вставлять код профиля разноски). Было принятно решение (не мной) - что будем вставлять RecId.
В результате - были получены на рабочей базе настройки, непереносимые в принципе. Т.е. нельзя было настроить все на тестовой, а потом перенести на рабочую, т.к. "разъехались" бы RecId.