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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.04.2015, 13:41   #1  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Find() vs Select
Добрый день.
Возник спор с разработчиками компании-внедренца: какую конструкцию лучше использовать для display-метода возвращающего например имя клиента.
Мой вариант:
X++:
return CustTable::find(accountNum).Name;
Вариант компании-внедренца:
X++:
select Name from CustTable
where  CustTable.AccountNum == accountNum;

return CustTable.Name;
Доводы что использование find прописано в ВР и также использует кэширование таблицы влияния не оказывает, говорят что запрос с выборкой одного поля будет отрабатывать быстрее.
Кто прав в итоге?
Старый 24.04.2015, 13:47   #2  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Они
__________________
Мы летаем, кружимся, нагоняем ужасы ...
Старый 24.04.2015, 13:51   #3  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Т.е. правильней везде вместо find писать select?
Старый 24.04.2015, 13:55   #4  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
как хорошо что возникают такие споры, значит других проблем особо нет
Старый 24.04.2015, 14:12   #5  
axm2013
Гость
 
n/a
Цитата:
Сообщение от AvrDen Посмотреть сообщение
..
Кто прав в итоге?
Вы.
Для поддержки лучше find, а по быстродействию не принципиально.
Старый 24.04.2015, 14:12   #6  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от AvrDen Посмотреть сообщение
Т.е. правильней везде вместо find писать select?
слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.
__________________
С уважением,
Вячеслав
Старый 24.04.2015, 14:18   #7  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от ice Посмотреть сообщение
как хорошо что возникают такие споры, значит других проблем особо нет
Или наоборот, куча сил уходит на такую ерунду, а модель расчета себестоимости за неделю до запуска обсуждают

Цитата:
Сообщение от pitersky Посмотреть сообщение
слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.
А также зависит от объема записи. Может, они туда memo-полей добавили?

В целом вариант партнера дает более предсказуемый результат, find в дисплей-методе - это точно BP? Можно ссылку?
__________________
Ivanhoe as is..
Старый 24.04.2015, 14:52   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Если бы вы выбирали кучу записей, то были правы бы они (меньший объем данные передавался бы в итоге по сети)

А в случае поиска единичной записи - правильнее find.
Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или
X++:
select Name from CustTable
where  CustTable.AccountNum == accountNum;
ядро все равно выберет все поля. И запомнит их в кеше
Плюс на уровне БД все равно с диска будет читаться страничка целиком где не только все поля лежат рядом но и куча рядом лежащих записей.
За это сообщение автора поблагодарили: trud (1), AvrDen (1), gl00mie (2).
Старый 24.04.2015, 14:53   #9  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Или наоборот, куча сил уходит на такую ерунду, а модель расчета себестоимости за неделю до запуска обсуждают
не надо на такую ерунду тратить время, если на быстродействие не влияет (а обсуждается дисплей метод), то нужно соглашаться с любым способом
За это сообщение автора поблагодарили: AvrDen (1).
Старый 24.04.2015, 15:07   #10  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Цитата:
Сообщение от pitersky Посмотреть сообщение
слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.
C железом проблем нет. На предприятии при наличии метода find() на таблице всегда отдавалось предпочтение ему. А сейчас будет получаться "винигрет", хотелось бы придерживаться единого стандарта.
Старый 24.04.2015, 15:10   #11  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Цитата:
Сообщение от Logger Посмотреть сообщение
Если бы вы выбирали кучу записей, то были правы бы они (меньший объем данные передавался бы в итоге по сети)

А в случае поиска единичной записи - правильнее find.
Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или
X++:
select Name from CustTable
where  CustTable.AccountNum == accountNum;
ядро все равно выберет все поля. И запомнит их в кеше
Плюс на уровне БД все равно с диска будет читаться страничка целиком где не только все поля лежат рядом но и куча рядом лежащих записей.
Да, выбирается единственная запись, поэтому и возник небольшой спор. Про кеш полностью согласен.
Старый 24.04.2015, 15:23   #12  
Napalm is offline
Napalm
Участник
 
80 / 88 (3) ++++
Регистрация: 23.05.2012
Для display метода вариант компании-внедренца более правильный - так как есть BP по использованию списков полей.

PS: Приведенный пример кода компании-внедренца безграмотный.
Старый 24.04.2015, 16:10   #13  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Napalm Посмотреть сообщение
PS: Приведенный пример кода компании-внедренца безграмотный.
По-другому может не сработать Уменьшение кол-ва полей в запросе
Старый 24.04.2015, 16:47   #14  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Кстати, есть еще зависимость от кода в методе CustTable::find(). Если не ошибаюсь, то в ранних версиях Axapta была безусловная настройка

X++:
custTable.selectForUpdate(_forUpdate);
что приводило к сильным задержкам выполнения. Т.е. сама эта команда вызывала задержку. Добавление условия, снимало проблему

X++:
        if (_forUpdate)
            custTable.selectForUpdate(_forUpdate);
Может, именно с этим связаны возражения внедренцев? По старой памяти, так сказать

А вообще, конечно, "лучше безобразно, зато единообразно". Раз для поиска одной записи используется find(), то его всегда и везде и следует использовать. Меньше будет проблем с поддержкой.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: macklakov (1).
Старый 24.04.2015, 17:50   #15  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Можно ссылку?
Находил вот это описание
https://msdn.microsoft.com/en-us/library/aa879893.aspx

Т.е. для поиска ОДНОЙ записи по ключу рекомендуется использовать find().
За это сообщение автора поблагодарили: macklakov (1), Ivanhoe (1).
Старый 24.04.2015, 17:54   #16  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение

Может, именно с этим связаны возражения внедренцев? По старой памяти, так сказать
Нет, у них был акцент на выборку именно одно поля.
Старый 24.04.2015, 18:17   #17  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Logger Посмотреть сообщение
Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или
X++:
select Name from CustTable
where  CustTable.AccountNum == accountNum;
ядро все равно выберет все поля. И запомнит их в кеше
Плюс на уровне БД все равно с диска будет читаться страничка целиком где не только все поля лежат рядом но и куча рядом лежащих записей.
Если не используется кеширование, то все равно будут читаться все поля?
__________________
Ivanhoe as is..
Старый 28.04.2015, 19:15   #18  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Гоните в шею таких внедренцев! Прирост в скорости - сотые доли процента. Метод find() должен быть на каждой таблице с уникальным индексом. Это обсуждалось неоднократно и записано в скрижалях по BP на первом месте. И если он есть, надо использовать. Если будете писать везде SELECT'ы, ваш код превратится в странно попахивающую кучу. Вы потом и сами будете неудобно себя чувствовать, показывая свой код другим.
__________________
// no comments
За это сообщение автора поблагодарили: macklakov (1).
Старый 28.04.2015, 20:03   #19  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
856 / 82 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
тоже отвечу, впрочем до меня уже все разжевали
лучше использовать find. не из-за производительности (как заметили верно - она если и различается, то несущественно)
главная причина: код короче и яснее, меньше вероятность ошибки
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
atinkerersnotebook: Using Service Management to Track Service Orders Blog bot DAX Blogs 1 25.08.2013 19:16
dynamicsaxtraining: Purchase Blog bot DAX Blogs 0 11.03.2012 05:25
dynamicsaxtraining: Select statement patterns Blog bot DAX Blogs 10 20.08.2010 14:01
Разница NotInTTS и Found Logger DAX: База знаний и проекты 6 18.09.2008 12:35
Вопрос про Demand Planner slava09 DAX: Функционал 4 25.09.2006 11:43
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:48.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.