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

[ax_mct]

На мой взгляд когда принимающая работу сторона может оценить работу только по результату то все должно быть максимально KISS (https://en.wikipedia.org/wiki/KISS_principle).

Постоянный работник может себе позволить сделать "красиво" в свое удовольствие, но фрилансер - нет. Решение должно быть железобетонным, пусть и "некрасивым". То есть надежность решения важнее чем "идеальность".

Как один из вариантов, можно создать вместо view реальную таблицу. Например EmplIDNameSearchIndex. Я так делал в ряде случаев. Да, костыль. Да, надо пару строк кода для синхронизации данных. Но еще раз, надежность и производительность важнее. Клиент нашу внутреннюю красоту оценить не в состоянии.

[mazzy]

Цитата:

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

Как один из вариантов, можно создать вместо view реальную таблицу. Например EmplIDNameSearchIndex.

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

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

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

[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 красивый, но не такой надежный.

[mazzy]

Цитата:

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

я бы добавил в EmplIDNameSearchIndex

в 2009 не поможет. поскольку:
1. в 2009 еще нет полнотекстового индекса (появился только в 2012)
2. пользователи по наименованиям обычно ищут что-то вроде "*Иванов*"
а по таким фильтрам SQL никогда индекс не использует. всегда будет full scan

Цитата:

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

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

угу. именно.

Цитата:

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

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

Повторюсь, это совсем не лучшее решение.
одно дело, full scan по таблице в 10тыс сотрудников + join фактов по полю с индексом.
другое дело, full scan по таблице фактов в 10млн записей.

и [не полнотекстовый] индекс - не поможет.

[ax_mct]

Цитата:

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

одно дело, full scan по таблице в 10тыс сотрудников + join фактов по полю с индексом.
другое дело, full scan по таблице фактов в 10млн записей.

и [не полнотекстовый] индекс - не поможет.

Как я понял EmplTable, как родительский datasource и обьект поиска, не подходит из-за логики возможного удаления из справочника работников.

Именно поэтому нужен список работников помимо EmplTable, именно в целях поиска и по историческим данным. Дополнительная таблица с несколькими полями. По ней ищем, к ней присоединяем факты.

Признак InActive Employee (удаленный работник) рано или поздно может быть полезен. Только на EmplId как на уникальный ключ я бы не полагался при этом.

KISS.

[mazzy]

Цитата:

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

KISS.

бгггг!
хорошая попытка

Цитата:

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

Задача: