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

[mazzy]

Задача:

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

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

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

==================
в 2012 ввели штатную возможность разыменования.
а как это правильно сделать в 2009?

в голову приходят следующие варианты:
1. join к таблице + ручное переопределение запроса. Пример - inventDim
2. кэшированный display-метод
3. что-то еще?

может подскажете примеры хорошей реализации в стандартном функционале?

[belugin]

Насколько я помню, фильры ввели в Ax2012, соответственно, если сделать outer join, то фильрация просто пойдет к условиям связи и вместо ограничения записей корневой таблицы, просто не покажет имя в несовпадающих по учловию записях. Возможно, можно сесть на research и переносить условия в еще один ExistsJoin datasource но мне сомнительно, что это гладко будет работать.

Остальные решения не предоставят сортировки и фильтрации по именованию или их надо будет делать отдельными контролами на форме.

[gl00mie]

Цитата:

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

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

Если всё так, как описано, то удаление сотрудника (записи с PK), на код которого есть ссылки в связанных таблицах (FK), - это нарушение целостности данных.

Цитата:

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

может подскажете примеры хорошей реализации в стандартном функционале?

Основное/Периодические операции/Проверка целостности данных Не знаю, почему, но этим функционалом пренебрегают на очень многих проектах, хотя вещь весьма полезная и позволяет сильно разгрузить программистов от решения типовых задач поддержки, связанных с нарушением целостности данных либо их (до)заполнением и т.п. Опять же, позволяет выбирать более "прямые" архитектурные решения.

[fed]

Есть такой вариант:
1. Сначала создаем view с outer join обоих таблиц. В поля вытаскиваем ключевое поле (или поля) первой таблицы и нужное разименование из второй.
2. На форме джойним созданную вьюшку через INNER JOIN к основной таблице формы.
Поскольку на форме все собранно inner join, тех проблем, о которых Belugin говорит - не возникает. Правда случаются проблемы производительности и в каких-то случаях все-таки бывает ситуации нелогичного поиска (кажется - когда ищешь строки с пустыми разименованиями). Но в целом - оно работает как пользователи хотят. Я применяю время от времени.

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

Цитата:

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

может подскажете примеры хорошей реализации в стандартном функционале?

А чем стандартная реализация через дополнительное поле в таблице не устраивет? PurchTable.OrderAccount + PurchTable.Name

[mazzy]

Цитата:

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

Насколько я помню, фильры

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

Цитата:

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

это нарушение целостности данных.

угу. еще какое!
и с этим надо жить.

Цитата:

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

2. На форме джойним созданную вьюшку через INNER JOIN к основной таблице формы.

кстати, тема. спасибо попробую.

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

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

А чем стандартная реализация через дополнительное поле в таблице не устраивет? PurchTable.OrderAccount + PurchTable.Name

ну... таких полей с кодом и наименованием - много. тупо хранить больше приходится. но объемы - это не главное.

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

причем искать = сканировать. поскольку люди все равно ищут при помощи фильтра "*Петров*". а для такого фильтра все равно идет полный скан, а индекс не используется. а полнотекстовый индекс появился только в 2012...

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

Цитата:

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

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

А сделать дополнительный вызов формы с документами из формы с фамилиями? Ну, по аналогии: Сведения о поставщике \ кнопка "Запросы" \ Заказ на покупку.

Ну, или тупо на форме "Заказ на покупку" добавить кнопку "Фильтр" \ "По поставщику", где и реализовать выбор с указанием фамилии.

Собственно, через расширенный фильтр вроде и так будет отображена фамилия при выборе. Чуть сложнее путь, но никаких модификаций вообще делать не надо. Можно по "тупой" кнопке "Фильтр" собственно и вызывать расширенный фильтр с преднастроенным Range по нужному полю.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

А сделать дополнительный вызов формы

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

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

Цитата:

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

а доп.форма - инструмент для отображения. но не для фильтрации исходных данных.

Под доп.формой я имел в виду нечто вроде: Главная книга \ Запросы \ Коды операций. Т.е. форма, где в удобном для пользователя виде, указываются критерии фильтра, который впоследствии и будет использован в основной форме.

[mazzy]

Цитата:

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

Есть такой вариант:
1. Сначала создаем view с outer join обоих таблиц. В поля вытаскиваем ключевое поле (или поля) первой таблицы и нужное разименование из второй.
2. На форме джойним созданную вьюшку через INNER JOIN к основной таблице формы.
Поскольку на форме все собранно inner join, тех проблем, о которых Belugin говорит - не возникает.

очень продуктивная идея.

проблема только с созданием новых строк.
несмотря на то, что в подчиненных датасорсах указано AllowCreate=No, AllowEdit=No, AllowDelete=No,
аксапта 2009 все равно пытается создать запись в подчиненном view. не может, естественно, выдает ошибку.
приходится из метода create, write убирать super.

но и в этом случае наименование отображается только после закрытия/открытия формы, либо после _ds.reseach

в общем, как-то некузяво. хотя поиск и фильтрация по наименованиям безусловно - вещь.

[fed]

Цитата:

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

но и в этом случае наименование отображается только после закрытия/открытия формы, либо после _ds.reseach

Есть более простой способ: на ссылочном поле в первой таблице в метод modified() добавляем примерно такой код:

MyView.custAccount=myTable.custAccount;
MyView.CustName=CUstTable::find(myTable.custAccont).Name;

Пока запись в аксаптовском буффере, значения полей сохраняются. Если пользователь проскролится и запись из буфера потеряется, то при следующем скролле в ту же запись, сиквел заново запрос перевыполнит и поля заполнит...

[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млн записей.

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

[gl00mie]

Возвращаясь к теме целостности данных, хочется еще раз вспомнить замечательную книгу Тома Демарко, Тимоти Листера и Ко Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд, а именно - паттерн №57 "КачИство данных"

Цитата:

Качество данных часто омерзительно. Печально распространенный подход к этой проблеме – поиск более совершенного программного обеспечения для обработки таких данных.

Качество программного обеспечения баз данных обычно превосходит качество самих обрабатываемых данных, однако с точки зрения конечного пользователя качество системы в целом определяется менее качественной составляющей. Компании повсеместно сталкиваются с базами данных, которые битком набиты неточными, устаревшими или неполными сведениями.
Эта проблема ясна как божий день, но, как любую очевидную вещь, ее бывает сложно разглядеть. Компаниям тяжело сразу примириться с собственными проблемами в области качества данных, хотя в чужом глазу все замечают соринку с легкостью. Поэтому они склонны видеть проблему в совокупности программного обеспечения и данных. А так как программное обеспечение всегда легче исправить, чем данные (ведь данных просто ужас как много!), компании занимаются исправлением программ или поисками заменителей.
Поскольку в этих действиях заведомо нет особого смысла, нам важно обсудить здесь не то, почему не следует заниматься исправлениями и поиском заменителей, а то, почему мы все же делаем это, хотя и не следовало бы. Отчасти причиной является разновидность улучшения новостей (см. паттерн 45): плохая новость о том, что 2,4 процента счетов в этом месяце были завернуты из-за ошибок в адресах, распространяется вверх по иерархии, на каждом уровне встречаясь с вопросом: «Блин, ну и что вы собираетесь с этим делать, причем побыстрее?»
Уточнение «причем побыстрее» немедленно исключает обширные исправления вручную. Расплывчатый ответ на этот вопрос: серьезные мероприятия по «чистке данных» начнутся как можно скорее. Эта прелестная фразочка проходит путь снизу до уровня директоров компании, на разных этажах означая разные вещи. У основания иерархии чистка данных означает, что кто-то сядет на телефон, зависнет в Интернете и перероет архивы переписки, чтобы изучить и исправить каждую некорректную порцию данных. Наверху это означает «работать умнее, чтобы каким-то образом породить правильные данные путем хитроумной обработки плохих данных». Поскольку финансирование поступает сверху, выделяемые бюджеты обычно предусматривают подход «работать умнее», а не оплату маленькой армии клерков, выполняющих реальную работу.
Стоит заметить, что данные могут быть просто попорчены (к примеру, в результате некорректных вычислений), и в этом случае существуют некоторые, по меньшей мере, частично автоматизированны способы откатить повреждения, обратившись к более ранним резервным копиям. Аналогичным образом, если одни и те же данные независимо записаны в нескольких системах, автоматизированная чистка данных может способствовать выбору правильных вариантов. В обоих случаях автоматизация опирается на возможность использовать избыточные данные. И хотя легко придумать пример, когда избыточность спасает (в системе А записан старый адрес, но – ура! – в системе Б записан новый), реальные случаи, когда низкое качество данных можно исправить автоматически, встречаются крайне редко.
Основная причина снижения качества данных со временем – это изменения. Такую порчу активов мы называем «корпоративностью данных», и лечится это только вручную. Думать иначе означает просто откладывать судный день.

[ax_mct]

Цитата:

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

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

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

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

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

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

KISS.

[mazzy]

Цитата:

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

KISS.

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

Цитата:

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

Задача: