ax2009: как правильно произвести разыменование кода? (добавить наименование)

[ax_mct]

Цитата:

Задача:

в таблице есть код (или несколько кодов) чего-то.
поставить рядом с кодом наименование этого чего-то.

ограничения:
= сохранить возможность сортировки, фильтрации по наименованию.
= наименование должно корректно отображаться рядом с кодом как в гриде, так и в закладках с подробными сведениями
= нужно отображать все записи исходной таблицы даже если в подчиненной таблице некоторые записи были удалены (outer join)

Пример:
общий журнал.
есть коды сотрудников, которые утвердили, отклонили журнал.
нужно добавить ФИО сотрудника рядом с кодом.
причем так, чтобы ФИО можно отображалось и в гриде
причем так, чтобы журналы отображались даже тогда, если какого-нибудь сотрудника удалят.

Цитата:

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

можно и так.
но реальную таблицу надо обслуживать, добавлять и удалять записи в ней.

кроме того, реальность такова, что целостность может быть нарушена. и в lookup-таблице могут отсутствовать записи.

в общем, хоть так, хоть эдак - закат солнца вручную.

Учитывая условие задачи "чтобы журналы отображались даже тогда, если какого-нибудь сотрудника удалят" целостность может быть нарушена безотносительно "индексной" таблицы.

Обслуживание стоит только строчку кода после super() в таблице сотрудников но в той же транзакции. Например EmplIDNameSearchIndex::insertOrupdate(EmplId, Name); Поскольку таблица сугубо служебная то можно при записи в нее emplIDNameSearchIndex.skipTTSCheck(true);

Учитывая что нужно данные из журналов показывать и по удаленным сотрудникам то я бы добавил в EmplIDNameSearchIndex (EmplId | EmplName) еще и checkbox InActive (неактивный/удаленный сотрудник) и соответственно ставил флаг EmplIDNameSearchIndex::markAsDeleted(EmplId). Дополнительно не делал бы только EmplId primary Key, включил бы RecId также.

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

Лучшим решением на мой взгляд было бы добавление EmplName в строку журнала и создание соответствующего индекса, если буфер записи и количество строк это позволяют.

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

И только после этого такие вот железобетонные но костыли. Предложенный подход с View красивый, но не такой надежный.