|
![]() |
#1 |
Banned
|
Цитата:
Задача:
в таблице есть код (или несколько кодов) чего-то. поставить рядом с кодом наименование этого чего-то. ограничения: = сохранить возможность сортировки, фильтрации по наименованию. = наименование должно корректно отображаться рядом с кодом как в гриде, так и в закладках с подробными сведениями = нужно отображать все записи исходной таблицы даже если в подчиненной таблице некоторые записи были удалены (outer join) Пример: общий журнал. есть коды сотрудников, которые утвердили, отклонили журнал. нужно добавить ФИО сотрудника рядом с кодом. причем так, чтобы ФИО можно отображалось и в гриде причем так, чтобы журналы отображались даже тогда, если какого-нибудь сотрудника удалят. Цитата:
Обслуживание стоит только строчку кода после super() в таблице сотрудников но в той же транзакции. Например EmplIDNameSearchIndex::insertOrupdate(EmplId, Name); Поскольку таблица сугубо служебная то можно при записи в нее emplIDNameSearchIndex.skipTTSCheck(true); Учитывая что нужно данные из журналов показывать и по удаленным сотрудникам то я бы добавил в EmplIDNameSearchIndex (EmplId | EmplName) еще и checkbox InActive (неактивный/удаленный сотрудник) и соответственно ставил флаг EmplIDNameSearchIndex::markAsDeleted(EmplId). Дополнительно не делал бы только EmplId primary Key, включил бы RecId также. Но данный костыль я например применяю когда просто деваться некуда, с учетом всех условий и требований. Лучшим решением на мой взгляд было бы добавление EmplName в строку журнала и создание соответствующего индекса, если буфер записи и количество строк это позволяют. Потом, как правильно уже написали, идет вариант с изменением UI когда поиск не через grid, а в отдельной функции-форме. Но тут непонятно с требованием поиска по удаленным сотрудникам, если их таки система даст удалить. И только после этого такие вот железобетонные но костыли. Предложенный подход с View красивый, но не такой надежный. Последний раз редактировалось ax_mct; 12.07.2015 в 21:17. |
|
![]() |
#2 |
Участник
|
в 2009 не поможет. поскольку:
1. в 2009 еще нет полнотекстового индекса (появился только в 2012) 2. пользователи по наименованиям обычно ищут что-то вроде "*Иванов*" а по таким фильтрам SQL никогда индекс не использует. всегда будет full scan Цитата:
Цитата:
одно дело, full scan по таблице в 10тыс сотрудников + join фактов по полю с индексом. другое дело, full scan по таблице фактов в 10млн записей. и [не полнотекстовый] индекс - не поможет. ![]() |
|
![]() |
#3 |
Banned
|
Цитата:
Именно поэтому нужен список работников помимо EmplTable, именно в целях поиска и по историческим данным. Дополнительная таблица с несколькими полями. По ней ищем, к ней присоединяем факты. Признак InActive Employee (удаленный работник) рано или поздно может быть полезен. Только на EmplId как на уникальный ключ я бы не полагался при этом. KISS. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#4 |
Участник
|
|
|
Теги |
как правильно, ключ, поиск, сортировка, фильтр |
|
|