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

[oip]

Цитата:

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

Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

У нас всех удовлетворяет, ибо ЕмплАйди у нас вида "АбрамоваСМ".

Вот с номенклатурами - да, беда.

[mazzy]

Цитата:

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

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

Кого-то не устраивает табельный номер?

Про Абрамову уже говорили.
Если она замуж выйдет, то стандартная процедура RenamePrimaryKey для изменения КОДА

[konopello]

Мда.. у нас тоже все начиналось с того что пользователи хотели видеть названия , краткие наименования (вначале отделывались закэшироваными display методами).
Со временем они начали осознавать что они хотят по ним и сортировать.... и все опять же сводилось к тому что нам так надо.... (как это не грустно, и попробуй ты доказать что в Axapta это делать надо не так), и на все по началу у них один ответ а вот у нас в 1С .... По началу хотел их убивать.... Жаль что я работаю на клиенте. Но один хоть плюс со временем смотришь что пользователи начали привыкать, ты начинаешь делать как надо делать, и они на это уже даже внимание не обращают….

[belugin]

на моей первой работе в медучреждении работники АСУ использовали ID в бытовом разговоре. Типа "Да у меня диагноз 300"

(я, кстати, помню, что там было 3 разных диагноза: "Алкогольное отравление в быту", "Алкогольное отравление в пути" и "Алкогольное отравление на работе" )

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

Цитата:

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

Цитата:

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

Да, есть несколько "широко известных" (в узких кругах ) сокращений. Ну и что? Это все работает до тех пор, пока справочник именно в этих пределах и ведется. Т.е. небольшой справочник. Как только размер справочника превышает некоторый предел, использование таких сокращений теряет смысл. Просто все их не упомнишь!

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

Вы прицепились к одному моему слову в ответе, я пояснил, что именно имею в виду.

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

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

Кстати, почти идеальный справочник - это Base Enum.

Поле на основе Enum - осуществляет поиск как по тексту (значению Lable), так и по коду (значение EnumValue). Записан код, а отображется название. Это как раз "классический" способ использования справочников.

[СибирскийКлещ]

Цитата:

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

...
Кстати, почти идеальный справочник - это Base Enum.
...

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

Есть подобное в некоторых системах, живут там люди без проблем с кодировкой справочников, возложив реляционные дела на недоступные пользователю "жирные" целочисленные 64-битные идентификаторы, которые кончатся к концу этого тысячелетия при скорости вставки 2 млн записей в секунду. Номера и коды используют только в визуальной пользовательской идентификации.

Но для Axapta это скорее всего утопия, что для нас , севших на ее иглу, есть грустный факт.

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

[mazzy]

Цитата:

Сообщение от СибирскийКлещ

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

Объясните как обеспечивается быстродействие при дополнительных join/select'ах для каждого такого поля.

Если под другими системами подразумевается 1С, то да... Это просто образцовый пример производительности

[СибирскийКлещ]

Цитата:

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

Объясните как обеспечивается быстродействие при дополнительных join/select'ах для каждого такого поля.

Если под другими системами подразумевается 1С, то да... Это просто образцовый пример производительности

Кэшируемый select только наименования из справочника, по типу кэширования display-методов, контроль исполнения подобного запроса в зависимости от видимости/невидимости поля может быть поможет и быстродействие съедобное поиметь, и с join-ами не заморачиваться

Ну почему же сразу 1С ? ГАЛАКТИКА, например ...
Хотя там только SQL-враппер для менеджера записей PSQL(сведения про версии до 8-ой ,про MS SQL и Oracle версию не в курсе, тем более про 8.хх, с которыми дела не имел), но каталог ОС с за-join-енными полутора десятками справочников и около сорока доп. таблиц вполне шустро листается.

Поднятый вопрос, в принципе, давно следовало ожидать - на дворе 3-е тысячелетие, космос и нанотехнологии, а тут до сих пор коды, коды, коды .