AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.07.2007, 18:10   #1  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,715 / 1204 (44) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy
Цитата:
Сообщение от Владимир Максимов
Да, есть несколько "широко известных" (в узких кругах ) сокращений. Ну и что? Это все работает до тех пор, пока справочник именно в этих пределах и ведется. Т.е. небольшой справочник. Как только размер справочника превышает некоторый предел, использование таких сокращений теряет смысл. Просто все их не упомнишь!
Согласен. Какой выход?
Ставить в код абстрактное число, а искать по наименованию?
Дык и наименования могут совпадать, есть тезки.
Вы прицепились к одному моему слову в ответе, я пояснил, что именно имею в виду.

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

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

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

Поле на основе Enum - осуществляет поиск как по тексту (значению Lable), так и по коду (значение EnumValue). Записан код, а отображется название. Это как раз "классический" способ использования справочников.
Старый 06.07.2007, 22:48   #2  
СибирскийКлещ is offline
СибирскийКлещ
Участник
 
26 / 11 (1) +
Регистрация: 24.11.2005
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
...
Кстати, почти идеальный справочник - это Base Enum.
...
В точку, только вот сортировки, фильтрации и регулировки наполнения черед БД нет .
А вот идея выбора из справочника значения по прямым информационным полям, их отображение в интерфейсе после выбора за счет изменения ключевого поля, значение которого скрытно для пользователя передалось из формы выбора в документ - просто чудесно бы смотрелась(и смотрится) при обеспечении нормального быстродействия.

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

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

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

Последний раз редактировалось СибирскийКлещ; 06.07.2007 в 22:50.
Старый 07.07.2007, 10:31   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от СибирскийКлещ Посмотреть сообщение
А вот идея выбора из справочника значения по прямым информационным полям, их отображение в интерфейсе после выбора за счет изменения ключевого поля, значение которого скрытно для пользователя передалось из формы выбора в документ - просто чудесно бы смотрелась(и смотрится) при обеспечении нормального быстродействия.
Объясните как обеспечивается быстродействие при дополнительных join/select'ах для каждого такого поля.

Если под другими системами подразумевается 1С, то да... Это просто образцовый пример производительности
__________________
полезное на axForum, github, vk, coub.
Старый 08.07.2007, 20:31   #4  
СибирскийКлещ is offline
СибирскийКлещ
Участник
 
26 / 11 (1) +
Регистрация: 24.11.2005
Цитата:
Сообщение от mazzy Посмотреть сообщение
Объясните как обеспечивается быстродействие при дополнительных join/select'ах для каждого такого поля.

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

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

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Абстрактный классификатор Maxim Gorbunov DAX: Программирование 52 17.01.2005 13:52
Централизованные справочники ZVV DAX: Прочие вопросы 12 02.09.2004 13:42
А есть ли в Аксапте стандартные российские справочники? edd DAX: Функционал 11 22.07.2003 05:49
Как заполнять основные справочники? renat DAX: Функционал 9 13.11.2002 17:39
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра
Комбинированный вид Комбинированный вид

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:49.