if (a == true)

[Vadik]

Цитата:

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

А отношение имеет прямое - просто показывает, что у нас нету жестких рекомендаций написания кода, поэтому все пишут "как хотят".

А вот это напрасно - хотя бы из уважения к людям которым потом эти письма дяди Федора разбирать и фиксить стоило бы этим озаботиться

[fed]

Цитата:

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

А вот это напрасно - хотя бы из уважения к людям которым потом эти письма дяди Федора разбирать и фиксить стоило бы этим озаботиться

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

[Napalm]

Цитата:

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

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

Меня вообще бесит использование списка полей. Например некоторые "оптимизируют" свой код так:

select forupdate BankAccount from custTable
    where custTable.AccountNum == "Account";
    
custTable.BankAccount = "BankAccount";
custTable.update();

[mayk]

Цитата:

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

Еще страшно злит, когда в selectах в явном виде указывают список полей. Причем я могу понять, когда это делают с учетом покрывающего индекса (например только recId извлекают). Но понять, почему те криворукие создания которые AIF разрабатывали, ухитрились напихать списки полей во все запросы - это выше моих возможностей...

Это вообще-то является BP

Цитата:

If a select statement is local to a method, use a field list to increase performance. If you use
a select or a while select statement and the size of the fields that are used total less than 50
percent of the total record size, a warning appears if you do not use a field list.

и существенно ускоряеет выполнение запросов, так как в сеть не пихается туча данных, из которых не используется и половина.

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

Что самое противное

    select Arrived from inventSum;
    print inventSum.AvailOrdered;

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

[fed]

Цитата:

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

Это вообще-то является BP
If a select statement is local to a method, use a field list to increase performance. If you use
a select or a while select statement and the size of the fields that are used total less than 50
percent of the total record size, a warning appears if you do not use a field list.

и существенно ускоряеет выполнение запросов, так как в сеть не пихается туча данных, из которых не используется и половина.

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

1. Есть покрывающий индекс состоящий из полей в списке выбора и условия where. (Надо помнить что все индексы неявным образом включают поля кластерного индекса. Так что некластерный индекс может покрывать больше полей чем вы ожидали.)
2. Если в таблице есть мемо-поля (контейнеры или строковые поля с длинной (Memo)). И те и другие долго подгружать и пересылать
3. Если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь ?
4. Ну и я бы пожалуй добавил случай экстремальной оптимизации. Скажем если мы засунули новый запрос в какое-то ключевое место нагруженных алгоритмов - типа закрытия склада,рассчета покрытия или ресурсного планирования, то экономия 3% на перекачку данных, в запросе, который исполняется миллионы раз, может оказаться выгодной

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

Этот пример еще раз подтверждает мою мысль что Аксаптовские Development Best Practice пишутся не для реальных проектов, а для разработки сферического коня в кубе...

[kashperuk]

Цитата:

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

Этот пример еще раз подтверждает мою мысль что Аксаптовские Development Best Practice пишутся не для реальных проектов, а для разработки сферического коня в кубе...

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

Так что милости просим к нам на работу, кто хочет изменить положение вещей и привнести реальный опыт внедрения АХ в код на SYS layer.

[ice]

Цитата:

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

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

Так что милости просим к нам на работу, кто хочет изменить положение вещей и привнести реальный опыт внедрения АХ в код на SYS layer.

а что мешает нанять таких спецов? просто в вакансии требования из "плюсов" перенесите в обязательные

[Napalm]

Цитата:

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

а что мешает нанять таких спецов? просто в вакансии требования из "плюсов" перенесите в обязательные

Ага, наймут спецов - а разработку продолжат аутсорсить в Индию.

[gl00mie]

Цитата:

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

С точки зрения производительности, выгодно указывать список полей если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь?

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

Цитата:

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

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

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