Find() vs Select

[AvrDen]

Добрый день.
Возник спор с разработчиками компании-внедренца: какую конструкцию лучше использовать для display-метода возвращающего например имя клиента.
Мой вариант:

return CustTable::find(accountNum).Name;

Вариант компании-внедренца:

select Name from CustTable
where  CustTable.AccountNum == accountNum;

return CustTable.Name;

Доводы что использование find прописано в ВР и также использует кэширование таблицы влияния не оказывает, говорят что запрос с выборкой одного поля будет отрабатывать быстрее.
Кто прав в итоге?

[TasmanianDevil]

Они

[AvrDen]

Т.е. правильней везде вместо find писать select?

[ice]

как хорошо что возникают такие споры, значит других проблем особо нет

Цитата:

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

..
Кто прав в итоге?

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

[pitersky]

Цитата:

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

Т.е. правильней везде вместо find писать select?

слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.

[Ivanhoe]

Цитата:

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

как хорошо что возникают такие споры, значит других проблем особо нет

Или наоборот, куча сил уходит на такую ерунду, а модель расчета себестоимости за неделю до запуска обсуждают

Цитата:

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

слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.

А также зависит от объема записи. Может, они туда memo-полей добавили?

В целом вариант партнера дает более предсказуемый результат, find в дисплей-методе - это точно BP? Можно ссылку?

[Logger]

Если бы вы выбирали кучу записей, то были правы бы они (меньший объем данные передавался бы в итоге по сети)

А в случае поиска единичной записи - правильнее find.
Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или

select Name from CustTable
where  CustTable.AccountNum == accountNum;

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

[ice]

Цитата:

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

Или наоборот, куча сил уходит на такую ерунду, а модель расчета себестоимости за неделю до запуска обсуждают

не надо на такую ерунду тратить время, если на быстродействие не влияет (а обсуждается дисплей метод), то нужно соглашаться с любым способом

[AvrDen]

Цитата:

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

слово "правильней" здесь весьма дискуссионно, ибо очень сильно зависит от того, что именно вам нужно. Если у вас настолько слабый сервер, что замена find на select даёт существенный рост производительности, то замена оправдана.

C железом проблем нет. На предприятии при наличии метода find() на таблице всегда отдавалось предпочтение ему. А сейчас будет получаться "винигрет", хотелось бы придерживаться единого стандарта.

[AvrDen]

Цитата:

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

Если бы вы выбирали кучу записей, то были правы бы они (меньший объем данные передавался бы в итоге по сети)

А в случае поиска единичной записи - правильнее find.
Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или

select Name from CustTable
where  CustTable.AccountNum == accountNum;

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

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

[Napalm]

Для display метода вариант компании-внедренца более правильный - так как есть BP по использованию списков полей.

PS: Приведенный пример кода компании-внедренца безграмотный.

[S.Kuskov]

Цитата:

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

PS: Приведенный пример кода компании-внедренца безграмотный.

По-другому может не сработать Уменьшение кол-ва полей в запросе

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

Кстати, есть еще зависимость от кода в методе CustTable::find(). Если не ошибаюсь, то в ранних версиях Axapta была безусловная настройка

custTable.selectForUpdate(_forUpdate);

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

        if (_forUpdate)
            custTable.selectForUpdate(_forUpdate);

Может, именно с этим связаны возражения внедренцев? По старой памяти, так сказать

А вообще, конечно, "лучше безобразно, зато единообразно". Раз для поиска одной записи используется find(), то его всегда и везде и следует использовать. Меньше будет проблем с поддержкой.

[AvrDen]

Цитата:

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

Можно ссылку?

Находил вот это описание
https://msdn.microsoft.com/en-us/library/aa879893.aspx

Т.е. для поиска ОДНОЙ записи по ключу рекомендуется использовать find().

[AvrDen]

Цитата:

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

Может, именно с этим связаны возражения внедренцев? По старой памяти, так сказать

Нет, у них был акцент на выборку именно одно поля.

[Ivanhoe]

Цитата:

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

Тем более что этот справочник наверняка кешируется ядром и тогда независимо от того как вы пишете - find или

select Name from CustTable
where  CustTable.AccountNum == accountNum;

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

Если не используется кеширование, то все равно будут читаться все поля?

[dech]

Гоните в шею таких внедренцев! Прирост в скорости - сотые доли процента. Метод find() должен быть на каждой таблице с уникальным индексом. Это обсуждалось неоднократно и записано в скрижалях по BP на первом месте. И если он есть, надо использовать. Если будете писать везде SELECT'ы, ваш код превратится в странно попахивающую кучу. Вы потом и сами будете неудобно себя чувствовать, показывая свой код другим.

[lvan]

тоже отвечу, впрочем до меня уже все разжевали
лучше использовать find. не из-за производительности (как заметили верно - она если и различается, то несущественно)
главная причина: код короче и яснее, меньше вероятность ошибки