Теоретический вопрос. Варианты связи таблиц.

[Владимир Максимов]

Вы перепутали причину и следствие

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

Цель использования Base Enum - это указание некоторого реквизита текущей записи таблицы

Тот факт, что Base Enum может быть указан в Relation - это "фича". Особенность. Вспомогательный, не основной, инструмент разработки

Предположим, у таблицы могут быть указаны "Сайт" и "Склад". Два поля.

1. Если заполнены оба поля, означает ли это, что данная запись не может быть применима ко всем другим складам этого же сайта?
2. Если поле Склад пустое - это ошибка ввода или запись применима ко всем складам указанного сайта?

Вы не может однозначно ответить на эти вопросы. Всегда будет некоторый элемент неопределенности. Всегда будет сомнение в корректности ввода данных.

Т.е. Вы вынуждены будете все-равно добавить еще одно поле Base Enum для того, чтобы однозначно идентифицировать соответствующее свойство записи

Замечу, что начиная с версии Ax2012 связь более чем по 1 полю считается устаревшей. Оставлена для обратной совместимости и облегчения перехода разработчикам на новые версии. Сделать-то можно, но проверка по Best Practices будет ругаться нехорошими словами, что, дескать, так не надо

Т.е. в данном примере в Ax2012 по Best Practices как раз и надо будет сделать 3 поля: Base Enum, Сайт, Склад. И Relation будет по каждой таблице в отдельности + Base Enum как идентификатор того, с чем работать надо


Можно, конечно, рассматривать Base Enum как некую альтернативу использования TableId. Но следует иметь в виду, что в этом случае критерием связи становится не физическая сущность (таблица), а некая логическая сущность (документ или тип документа).

Совсем не обязательно, что разные значения Base Enum - это разные таблицы. Это вполне могут быть одни и те же таблицы, но являющиеся разными "документами". Например, разные типы складских журналов. Ну, или классический InventTableModule