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

[konopello]

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

[belugin]

Цитата:

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

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

Ну, обычно люди еще хотят ФИО рядом видеть...

Вообще, получается, что я один такой несчастный, что все от меня наименования требуют. Остальных удовлетворяет значимый ID и только он и дисплей методов типа

display EmplName emplName()
{
     return (select firstOnly EmplName from EmplTable 
             where EmplTable.EmplID == this.EmplID).EmplName;
}

никто не пишет?

[belugin]

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

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

[mazzy]

Цитата:

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

Вообще, получается, что я один такой несчастный

Почему ты так решил?
Это постоянная тема.
См. например ссылку на обсуждение Абстрактного классификатора и поищи обсуждения по ключевому слову лукап/lookup


Анекдот:
Жена (Ж) звонит на мобильный мужу (М).
(Ж) - дорогой, будь осторожен, по радио сообщили, что какой-то идиот едет по встречной полосе
(М) - да их тут сотни!

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

Цитата:

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

Цитата:

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

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

Почему это "суррогатный" и почему не информационное?

Когда начинается спор СК vs ЕК у меня возникает вопрос, а о чем собственно спорим? Т.е. где определения того, что понимать под термином "естесственный ключ", а что под термином "суррогатный ключ". Это понятия, которые все "интуитивно" понимают, но как только дело доходит до определений, все смешивается в жуткую кашу.

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

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

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

Меня не интересует ни способ формирования СК или ЕК, ни то, вкладывает ли в них пользователь какой-либо физический смысл или нет. Все это "вторично".

Собственно, в моем понимании СК и первичный ключ практически синонимы. Как именно они формируются: автоинкремент, GUID, номерная серия, ручной ввод - не имеет никакого значения. Если он предназначается и обеспечивает однозначную идентификацию записи всегда и при любых условиях, то для меня это "суррогатный ключ".

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

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

Теперь, почему "не информационные"?

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

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

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

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

Именно поэтому я и называю такие поля "не информационные". Они требуют "расшифровки". Сами по себе никакой информации, кроме однозначной идентификации записи не несут.

[mazzy]

Цитата:

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

Именно поэтому я и называю такие поля "не информационные". Они требуют "расшифровки". Сами по себе никакой информации, кроме однозначной идентификации записи не несут.

"Светик" не несет никакой информации?
Склады с кодом Основной, Южный, Порт?
Город с кодом Мск, Спб и т.п.?
Группы VIP, Розн, Рынки, Школы, Прочие, Наши, Левые?

Не несет, значит никакой информации.
Как скажете...

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

Цитата:

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

"Светик" не несет никакой информации?
Склады с кодом Основной, Южный, Порт?
Город с кодом Мск, Спб и т.п.?
Группы VIP, Розн, Рынки, Школы, Прочие, Наши, Левые?

Не несет, значит никакой информации.
Как скажете...

Если на юге построили еще один склад, то Южный - это какой из них?

Красн - это Краснодар или Красноярск? АБВГ - это какой город?

Если после VIP появились VIP1 и VIP2?

Вы помните свою аргументацию, по поводу использования древовидных справочников? Ведь все понятно же! Кому понятно? Тому, кто сам эти обозначения и придумал! Сам их отслеживает.

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

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

Как скажете...

[mazzy]

Цитата:

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

Если на юге построили еще один склад, то Южный - это какой из них?

А что говорят пользователи?
Они как называют новый Южный склад?
То и будет в коде.

Цитата:

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

Красн - это Краснодар или Красноярск? АБВГ - это какой город?

Если после VIP появились VIP1 и VIP2?

А что говорят пользователи?

Цитата:

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

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

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

Цитата:

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

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

Да, там была алтернатива - вытянуть дерево в линейный список и поискать.
Здесь я альтернативы не вижу.

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

В общем, имеющаяся альтернатива - подставлять наименования - не дешевле и не удобнее, нежели информативные коды.

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

Цитата:

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

Цитата:

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

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

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

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

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

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

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

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

[Zepp]

Цитата:

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

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

К сожалению изменить EmplId через "Паспорт записи" недостаточно (AX 3.0 SP4 EE). При создании строки в EmplTable создается строка в таблице RHRMVirtualNetworkTable, при этом ключевому полю hrmVirtualNetworkId присваивается значение поля EmplId. При изменении кода в EmplId, код в hrmVirtualNetworkId останется прежним - в результате нельзя будет создать нового сотрудника в EmplTable с прежним кодом.

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

Цитата:

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

...
Кстати, почти идеальный справочник - это 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-е тысячелетие, космос и нанотехнологии, а тут до сих пор коды, коды, коды .