Правильные справочники

[belugin]

Есть устойчивая концептуальная проблема со справочниками.

Она исходит из двух посылок:
1. Аксапта практически не использует суррогатных ключей.
2. Аксапта не поддерживает вывод наименования рядом с кодом в ссылке на справочник

Соответственно, во-первых, кто-то должен присваивать идентификаторы для кодов справочников отличные от их наименования.

Во-вторых, для вывода описаний значений справочника надо делать дополнительный код (обычно, дисплей-методы)

В-третьих, фильтрация по наименованиям затрудняется (при этом часто ее требуют): либо для фильтрации нужно лезть в дополнительную форму либо надо программировать дополнительные контролы для ввода параметров фитльтра?

Кто как решает эту проблему?

Я встречал два противоположных способа и их горячих сторонников.

1. Идентификаторы делают длинными и осмысленными -- соотвественно они требуют переименования при изменении названия значения

2. Идентификаторы делают неосмысленными или они содержат небольшой условный префикс и номер типа спирт001.

Какой по вашему должны быть структура справочника?
Есть ли у вас проблема того,что пользователи требуют фильтрацию по наименованию прямо в гриде?

P.S я знаю что для обязательных атрибутов это решается более-менее приемлемо.

[belugin]

В догон: одной из первых моих реальных задач на Аксапте было прилепление названия номенклатуры в строки закупок, складских журналов и т.д.

Есть ли люди пользователям которых достаточно видеть коды номенклатуры в этих местах и как они этого от пользователей добились?

[kashperuk]

Ответом это не будет, но расскажу, как сделали у нас.
название номенклатуры так и выводят дисплей методами (редко через доп. источник - в случае, когда еще пару полей из ном. справочника тоже надо выводить)
но у нас есть еще одно поле - каталожный номер (типа второй код номенклатуры). Нужны оба кода, (один - реальный код, второй - из 1С). и искать хотят, ессно, по обоим.

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

пока проблем не было. Производительность выше. А база данных не намного больше размером (поле то всего одно).
Но, конечно, это не выход в общем случае.

[belugin]

А коды какие используюте? осмысленны или номера?

[kashperuk]

Цитата:

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

А коды какие используюте? осмысленны или номера?

ItemId - из 1С (то есть код номенклатуры, используемый в 1С до внедрения Аксапты)
CatalogNum - общепринятое название запчасти - менеджерам проще его использовать некоторым.

[KiselevSA]

В номенклатуре используем артикул, который абстрактный, но несет в себе некоторую нагрузку (группы товаров, подвид и т.п.), описание пришлось тащить везде, т.к. при небольшом наборе активных позиций быстрее работать с артикулами (причем числовыми с использованием некотрых разделителей), да и индексировать поля длиной не более 12 символов легче, чем по названиям в пятьдесят.
А вот там, где одно из ключевых полей достаточно коротко, можно отойти от кодировния. Так поступили, например, с городами и улицами.

[slava09]

Нужен более концептуальный механизм. Что-то вроде определения аттрибутов в справочнике, которые понадобятся для анализа\поиска\сортировки. И вывода их куда-то, по какой-то кнопке и возможностью их скрытия. Завтра идею разработаю подробно.

[belugin]

Цитата:

Нужен более концептуальный механизм

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

[Vals]

Цитата:

одной из первых моих реальных задач на Аксапте было прилепление названия номенклатуры в строки закупок

Оно там есть в стандарте.

[kashperuk]

Цитата:

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

Оно там есть в стандарте.

Имелось ввиду, думаю, возможность сортировки и фильтрации по названию номенклатуры в строках закупок/заказов

[belugin]

Цитата:

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

Имелось ввиду, думаю, возможность сортировки и фильтрации по названию номенклатуры в строках закупок/заказов

Не, это я ошибся, наверное. За 3 года какую-то конкретную форму перепутал. Но я помню там была куча форм. Если кто-то собирается писать мою биографию, могу попросить раскопать, каких именно.

[glibs]

На моей памяти добавление названия номенклатуры с возможностью поиска и сортировки в запрос в наличии и в форму создания строк заказов и закупок (+ форма создания строк журналов переноса, содранная с заказов).

В строках складских журналов добавляли display-методом. Может еще где-то.

Клиенты и поставщики нужны были с фильтрацией и сортировкой в заказах и закупках. Решалось закрытием редактирования поля SalesName и аналогичного в закупках. Возможно, к Счету на что-то джоинилось.

Чего-то мне не запомнилось особенно много мест, где очень важно искать и сортировать именно по имени клиента.

Может вам стоит задуматься над архитектурой решения? У вас точно все в порядке, если вам сплошь и рядом нужен поиск и сортировка по... ну ладно по номенклатуре... но вы же наверное видели, что пользователи пишут в имени клиента...

[belugin]

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

Как я понял, номенклатуру обычно кодируют по номерам, потому что ее много и названия сложные, а клиентов - по именам, потому, что часто названия есть короткие типа

ЗАО Флористическая Компания "Цветочек"

можно удобно сократить до

Цветочек

и даже если она поменяет название на "Кактус" то пользователи по старой памяти могут продолжать называть ее "Цветочек"

[glibs]

Цитата:

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

...
номенклатуру обычно кодируют по номерам, потому что ее много и названия сложные, а клиентов - по именам
...

Не факт. Я чаще встречал цифровую кодировку клиентов.

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

Кодировка номенклатуры куда важнее. Точнее, даже не кодировка, а классификация. Был свидетелем занимательного процесса кодировки номенклатуры, когда клиент сначала (серьезно, долго и старательно) пытался построить дерево, а потом выкинул его нафиг, так как менеджмент не смог договориться о принципах классификации (у каждого было свое мнение), и сошлись на взаимозависимых фильтрах "как в Excel".

Возможно, для ваших справочников подойдут какие-то принципы из тех, которые применимы для клиентов или номенклатуры.

[belugin]

Еще вопрос, а кто работает номерной серией в случае номерной кодировки?

[twilight]

Цитата:

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

Еще вопрос, а кто работает номерной серией в случае номерной кодировки?

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

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

С чисто формальной стороны, то, что используется в AXAPTA и есть суррогатный ключ, поскольку это не есть информационное поле. В смысле, поле, содержащее некую осмысленную информацию о сущности. Это просто идентификатор записи.

Другое дело, что, как правило, суррогатный ключ используется для внутренних механизмов обеспечения ссылочной целостности и пользователю не показывается. Пользователь видит как раз "Имя", а не "Код".

А в AXAPTA пошли более простым путем - дали пользователю возможность напрямую как просматривать, так и вводить коды записей. Поэтому возникла иллюзия того, что это "естесственные ключи". На самом деле это не так. И об этом надо всегда помнить.

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

Суть в том, что таблица-справочник цепляется по JOIN к основной таблице и в Grid отображаются напрямую поля из таблицы-справочника. Никаких дисплейных методов и дополнительных полей.

Работают все штатные механизмы поиска и фильтрации. Более того, через расширенное окно поиска можно задать критерии отбора по полям, не отображаемым на форме.

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

[belugin]

Цитата:

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

С чисто формальной стороны, то, что используется в AXAPTA и есть суррогатный ключ

Мне нравится понятие искусственный ключ.

Цитата:

Суть в том, что таблица-справочник цепляется по JOIN к основной таблице и в Grid отображаются напрямую поля из таблицы-справочника. Никаких дисплейных методов и дополнительных полей.

Ага я про это знаю...

[kashperuk]

Основаня проблема предложенного подхода, описанного Вами, заключается в том, что после определенного числа источников (7 вроде) они перестают работать.
+ если неправильно построены они иерархически, то перестать работать они могут и раньше. А именно так обычно и получается, когда добавлять поля надо в существующие формы.

[belugin]

Можно попробоваь направить пожелание MS через программу TAP по поводу работы со справочником. Я пока вижу следующее:

• В EDT добавить свойство с названием типа "Добавлять поля заголовка"
• Если свойство установлено, то тех случаях, когда по полю с этим EDT автоматически генерируется контролы (например, если оно является частью группы присвоенной какому-нибудь элементу управления или его перетаскивают из DataSource на форму), это поле должно отображаться в группу в которую входят:
  • или поля составляющие специальную группу "TitleFields" на таблице, на которую сслыается EDT
  • или поля titleField1, titleField2 этой таблице если в TitleFields нет полей