Строить ли relation на RecId?

[nebraska]

Дано - несколько таблиц, к которым необходимо привязать еще одну. Решаю между 2мя вариантами - добавить в каждую из таблиц новое поле, или связаться полями RecId + TableId.

Как лучше сделать? Неохота городить новые поля и новую номерную серию + следить, чтобы эти поля всегда заполнялись.

Какие могут быть грабли при использовании связей на RecId + TableId?

Заранее спасибо за ответы.

[DSPIC]

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

[ZVV]

Цитата:

Сообщение от nebraska

Дано - несколько таблиц, к которым необходимо привязать еще одну. Решаю между 2мя вариантами - добавить в каждую из таблиц новое поле, или связаться полями RecId + TableId.

Как лучше сделать? Неохота городить новые поля и новую номерную серию + следить, чтобы эти поля всегда заполнялись.

Какие могут быть грабли при использовании связей на RecId + TableId?

Заранее спасибо за ответы.

Если кратко:
Как выполнять дефрагментирование RecID

[sukhanchik]

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

В общем-то - это все так... личные предпочтения. Как было замечено выше - при правильном (по MS) подходе - все будет ок.
Но когда-то ранее уже всплывали темки типа а как перейти с SQL Server на Oracle, которые в принципе по MS-ному не делаются . Но при желании делаются в жизни. Так и тут. Я лично предпочту по максимуму избежать связок по RecId именно в рамках облегчения администрирования.

Кстати. На одном из проектов - возникла необходимость код строки настроечной таблицы вставлять в транзакционную таблицу (ну это тоже самое, что в бух проводки вставлять код профиля разноски). Было принятно решение (не мной) - что будем вставлять RecId.
В результате - были получены на рабочей базе настройки, непереносимые в принципе. Т.е. нельзя было настроить все на тестовой, а потом перенести на рабочую, т.к. "разъехались" бы RecId.

[mazzy]

Цитата:

Сообщение от sukhanchik

+ Универсальность связки. Когда несколько исходных документов прилинковываются к одному журналу - это удобно.

Не. Нет этого плюса.
RecID позволяет привязать любую таблицу. Именно ЛЮБУЮ. Только в коде приходится постоянно гадать "какая таблица прилинкована?" и проверять, проверять, проверять. В лучшем случае делают два поля TableId и RecID.

Но вместо этого лучше пользоваться составлными ключами из двух полей (Tag, RefCode). Настроив связи между НУЖНЫМИ таблицами в АОТ. В этом случае вообще БЕЗ программирования достигается и переход к основной таблице, и validate, и lookup.

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

http://axapta.mazzy.ru/lib/numbersequence/
http://axapta.mazzy.ru/lib/numbersequence_using/
http://axapta.mazzy.ru/lib/numbersequenceformat/

[sukhanchik]

2mazzy: Я и не говорил о том, чтобы использовать RecId без TableId. Одно без другого не живет.
А вот как предполагается в таком случае связывать таблицы при необходимости сделать некий лог/журнал/историю в которую сыпятся данные из разных мест?
Или другой пример. Я хочу "наклепать" журналы ГК (складские журналы и т.д.) из некой своей надстройки. Я хочу сделать связку. Мне очень нравится идея (за вычетом моих минусов) прописать в ЖГК TableId, RecId со ссылкой на мой исходный документ. Независимо от того - какие ключи у меня в таблицах используются.

В принципе - все решаемо номерной серии. Ведь даже корреспонденция (связка) сделана через номерную серию.

Понятно - что одно из решений проблемы - подойти к ней с другой стороны и решить ее другим способом. Но тем не менее - моя модель - она вполне может быть вероятна. Нет?

[TasmanianDevil]

sukhanchik, в корреспонденции не только номерная серия - там еще и RecId во всю используется

По поводу ЖГК и ссылок таких в нем - а зачем именно там ?
Такое , IMHO, лучше делать в самих проводках ГК. Расширить одноуровневую связь "Voucher+TransDate" до многоуровневой "Voucher+TransDate" + "Код таблицы+код записи"(по документу) + "Код таблицы+код записи"(по позиции документа). В результате можно поиметь очень гибкий и детальный механизм детализации связей документов, их строк и порожденных ими модульных проводок с проводками ГК. Если эти ссылки использовать как доп. элементы группировки проводок в режиме Summary, то про недостатки этого режима можно забыть.

[sukhanchik]

2TasmanianDevil:
Согласен - это в целом - более гибко.
ЖГК чем хорош - тем, что:
1. Можно написать функционал, который его распроведет (с удалением проводок) - чего нельзя прикрутить к LedgerTrans
2. Если на проекте есть новички - то научить их "клепать" из кода ЖГК проще, нежели - проводки. Хотя это и организационный момент - который должен решаться больше организационно.

Я не утверждаю, что ЖГК лучше - более того - я согласен - что более красиво будет реализация идеи TasmanianDevil. Просто ... исторически так складывалось - что я сталкивался больше с "клепанием" ЖГК.

[mazzy]

Цитата:

Сообщение от sukhanchik

2mazzy: Я и не говорил о том, чтобы использовать RecId без TableId. Одно без другого не живет.

Начинается... В минусах ничего про TableID не было

Цитата:

Сообщение от sukhanchik

А вот как предполагается в таком случае связывать таблицы при необходимости сделать некий лог/журнал/историю в которую сыпятся данные из разных мест?

как обычно: тег + код.
делайте перечисление, каждое значение которого означает таблицу.
Используйте код таблицы.

Четко управляйте своим кодом.
Не допускайте произвольных связей в runtime...

Цитата:

Сообщение от sukhanchik

Или другой пример. Я хочу "наклепать" журналы ГК (складские журналы и т.д.) из некой своей надстройки. Я хочу сделать связку. Мне очень нравится идея (за вычетом моих минусов) прописать в ЖГК TableId, RecId со ссылкой на мой исходный документ. Независимо от того - какие ключи у меня в таблицах используются.

Мне это очень напоминает споры бейсиководов с паскалеводами насчет типизации.
Или споры Сишников с Сплюс-плюсистами по поводу типизации...

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

Цитата:

Сообщение от sukhanchik

Понятно - что одно из решений проблемы - подойти к ней с другой стороны и решить ее другим способом. Но тем не менее - моя модель - она вполне может быть вероятна. Нет?

Да.
Если очень нравится - делайте.
Просто надо понимать, что это заметание проблем под коврик.

Будете трахаться в отладчике
Будете трахаться с отсутствующими перекрестными ссылками (они не учитывают tableID в данных).
Будете трахаться с налаживанием связей в запросах и в отчетах вручную.
Будете трахаться с экспортом/импортом девелоперских проектов (обязательно с сохранением кода объектов)
Будете трахаться с экспортом/импортом данных (каждый обрабатываемый recID увеличивает время импорта).

Зато сэкономите десяток минут во время разработки связи и, возможно, полчаса на нумераторе.

[Raven Melancholic]

Цитата:

Сообщение от mazzy

Зато сэкономите ... возможно, полчаса на нумераторе.

Хочу начальника, который на нумератор полчаса дает

[sukhanchik]

2mazzy. Это все увы, я знаю. И согласен - что енум+значение лучше, чем TableId+RecId. Просто в свое время небезызвестный VALU (Валера Ушаков) меня мож сказать убедил, что TableId+RecId универсальнее. Точнее сказать - пришлось поскандалить и согласиться.

Поэтому могу сказать так. Енум+номерная серия - это правильнее и оставляет за собой меньше граблей. Во всех смыслах. Но при этом поле с номерной серией нужно добавлять как идентификатор во все таблицы-источники.
Однако, имеет смысл призадуматься о TableId+RecId, если таблиц-источников много И они представляют собой стандартные таблицы. Получится много изменений в стандарте. А при обновлении приложения (подъеме на сервис-пак) - чем меньше перекрытых объектов и использующихся стандартных объектов - тем проще и быстрее обновляться.
Хочу еще раз отметить - призадуматься - не значит выбрать.
И наконец, самое главное. Любую задачу (с т.з. консультанта) можно решить по-разному с разным кол-вом доработок. Поэтому - любая "неудобная" разработка прежде,чем начаться должна быть обсуждена на предмет "а нет ли лучшего пути решения исходной задачи"?