Цитата:
Задача:
в таблице есть код (или несколько кодов) чего-то.
поставить рядом с кодом наименование этого чего-то.
ограничения:
= сохранить возможность сортировки, фильтрации по наименованию.
= наименование должно корректно отображаться рядом с кодом как в гриде, так и в закладках с подробными сведениями
= нужно отображать все записи исходной таблицы даже если в подчиненной таблице некоторые записи были удалены (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 красивый, но не такой надежный.