Ребят, а где поискать методические материалы по конфигурированию и разработке решений на 1С? Встречал на its.1c.ru но теперь там найти не могу эту информацию. Что-то вроде "типичные ошибки разработчика". Кодер строит отчёты, использует документы, справочники, совершенно не пользуется регистрами. Бывший семёрочник. Мозги работают но направить в нужное русло надо. В запросе обращается к реквизитам через точку - до пяти вложений. В общем, хотелось бы скорректировать человека.

http://v8.1c.ru/metod/books/book.jsp?id=401

>> В запросе обращается к реквизитам через точку - а что в этом плохого?

(2) В 77 это не очень.

и в 8.х, если результаты запроса потом через "." обрабатываются.

Найди другого программиста. Если чел кодил ещё на семере и до сих пор так лажает, его только могила исправит.

(2) меня интересует: зачем делают инструмент, которым лучшене пользоваться? я лично через точку обращаюсь и не парюсь

(2)
ВЫБРАТЬ
  Документ.Договор.УсловияДоговора.График.ДатаОплаты

Что в этом плохого сам поймёшь?

(7) нет, расскажи

(5) Да не, жалко. Тем более, что с алгоритмической составляющей у него полный порядок. Вот пишет абы как. Попробуем перевоспитать.

(8) На троллинг не поддаюсь.

(10) а потом человек уйдет из 1С в нормальный SQL и узнает, что NULL таки нормально хранится в полях и еще есть внешние ключи

(7) А как надо-то?

(7) И что же тут плохого?

(6) надо просто понимать когда это опасно и чем может угрожать

http://webfile.ru/6413242 - что то такое валяется у меня вот...

(11) Я за него только порадуюсь.

(15) Спасибо!

(0) в семерке не было регистров чтоль, что он к ним не обращался?

Через точку без проблем, если тип не составной.
Попробуй у реквизита ЛюбаяСсылка прочитать ПометкаУдаления :)

(7) Тут нормально
Хуже, если ченить вроде:

ВЫБРАТЬ
   Субконто1.Договор.Номер
ИЗ
   РегистрБухгалтерии.Хозрасчетный.Обороты()

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

Вообще много точек, по крайней мере в семерке, 1С сильно не любит, но иногда влом и использую такое. Вот совсем недавно в семерке нарвался, что если через много точек сделать в документе выборку строк, то 1С вместо смены строк последовательно, крутится на первой строке :-(, очень был удивлен такой засаде :-)

(0) Автор ветки не_асилил разыменование полей?

(21) можно и через точку, при условии грамотных отборов, преобразований типов.

Через точку крайне хреново. Ваш запрос 1С придется "разузловывать" при трансляции на TSQL и не факт, что это будет сделано оптимальным способом.

(25) Это повод превратить код в нечитаемое УГ?

(26) Хорошая читаемость - это повод для того, чтобы запрос выполнялся неоптимально, медленно и грузил ресурсы?

через точку, но с явно типизацией

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

http://kb.1c.ru/articleView.jsp?id=44

под (7) ни один пункт не подпадает

(27) "Г@внокод с оптимизацией" - пережиток прошлого, читаемость намного важнее.

собстна, вот же, что имеет автор в виду: получение данных через точку от полей составного типа; - поля составного типа..

(31) а чо там составного типа то?

(32) где "там"??..

(33) в (7).
Если там есть что-то составного типа, то да, надо либо Выразить вставлять либо еще как-то обходить. Если уже есть полученные данные по условиям например  другой временной таблице, то можно как то из них выцепить.

А так нормальный код

(30) я бы таких сразу увольнял.
То есть лучше 5 строк кода выполняющихся 10 минут, вместо 50 строк кода, выполняющихся за 1 минуту?

(34) собстна, я про автора - "В запросе обращается к реквизитам через точку "... строю предположение, почему автору не нравится обращение реквизит через точку - потому что, не рекомендуется для составных полей обращаться через точку..

(35) не надо скатываться в крайности, г@внокод по определению плохо, но при качественном написании кода часто наступает момент, когда нужно жертвовать или скоростью или читабельностью. Частенько менее опытные программисты готовы полностью пожертвовать читабельностью за счет ускорения на  0.0001с.

да, "менее опытные" даже заморачиваться не будут на производительность

(38) да они начитаются статей по верхам, а потом делают что то вроде

Для Каждого цСтрока Из Товары Цикл цСтрока.Артикул = цСтрока.Номенклатура.Артикул; КонецЦикла;

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

(35) А по моему мнению, увольнять нужно г@внокодеров.

(37),(40) код всегда должен быть читаемым и понятным! Просто большой объем кода - это еще не означает "г@внокод".
Лучше 50 строк понятного кода, но реально быстрого, чем 5 строк понятного, но реально медленного кода.

(41) >>код всегда должен быть читаемым и понятным

+(41) очень часто запрос на 10 строчек, можно ускорить в 5-20 раз, увеличив объем запроса до 50 строк.

+(42) это иллюзия, как пример охеренные запросы в типовых, который оптом через кучу временных таблиц подготавливают данные для проведения. Это нифига не читабельно, но сделать так же быстро и читабельно не получится

а что за такой запрос можно сделать?
Выбрать Номенклатура.Ссылка, Номенклатура1.Ссылка
Из Справочник Номенклатура как Номенклатура, Справочник Номенклатура как Номенклатура1
))

(45) это на конкурс "Уронить базу за меньшее количество строк кода"?

(46) ну, можно и для тестирования ноута)...

(44) Если Вы не умеете читать большие запросы, это Ваша проблема. Если запрос написан верно без глупых ошибок в условиях (это мелочи), то он может быть очень большим, и это нормально.

(48) уметь читать большие запросы и читабельность кода это все же разные вещи.

(49) Кто определяет читабельность кода? Нечитабельный код = г@внокод?

(45) Зависит от размеров справочника номенклатура, имхо

(50) >>Кто определяет читабельность кода?

ну тут кто как меряет, кто в "F@ckах" в минуту на аудите, кто в количестве обнаруженных запахов кода по Мартину, а ктото по ощущениям. Обычно более менее очевидно, какая запись читабельнее. Но у нас частенько холивары на эту тему всплывают на аудитах.

>>Нечитабельный код = г@внокод

Нет. Нечитабельный код может быть следствием гКода или агрессивной оптимизации (оптимизации в ущерб читабельности), запросы, которые под 500-1000 строк кода могут быть идеальными, но плохочитабельными. А гКод может быть читабельным, правда это редкость

(7) Э.. вообще помоему в курсах Чистова именно это и рекомендовалось, где только возможно тянуть данные через точку. Уволить Чистова за профнепригодность?

(53) надо понимать, где можно тянуть данные через точку, а где нельзя.

(54) Надо понимать, что ты говоришь именно про запрос или про денормализацию БД, ты привел конкретно кусок кода, но ни слово не сказал, что эти данные где-то еще можно достать или изменить структуру БД.

+(55) Сорьки, конечно не ты, а человек так сказал :)

(52) Я говорю, что "нечитабельный" некоторыми людьми код не является г@внокодом. Если оптимизация из примера (37) всего на 0.0001с, и увеличение кода в разы, при этом написано абы как, вот это г@внокод.
А если выполнена оптимизация в 5-10 раз процедуры, которая запускается каждые несколько минут сотней пользователей, при этом код с 20 строк увеличен до 500-1000 строк, то это можно назвать профессиональным кодом. И если кто-то такой код не способен понять - это его проблемы, и его уровень профессионализма.

(45) Вспомнился Лустин: Выбрать * ИЗ * :)

Вот это говнокод?

ЗначениеИзСтрокиВнутр("{""#"",51e7a0d2-530b-11d4-b98a-008048da3034,{0,{""S"",""" + СтрЗаменить(СтрЗаменить(Строка, """", """"""), Разделитель, """},{""S"",""") + """}}}")

А как правильно построить запрос через точку, если тип данных составной?

Закладка

(61) Есть такая кнопка внизу !

(62) у кнопки косяк - она не отмечает, докуда ты дочитал

(59) Если данный код заменяет другой код, и выполняется в 5-10 раз быстрее, и невозможно заменить на понятный, но при этом работающий так же быстро код, и обязательно с комментарием, описывающим выполняемое действие, то это нормальный код.
При всем этом если данный код дает ускорение на миллисекунды, и используется слишком редко, то это гвнокод.
Всегда зависит от контекста. А судить гвнокод или нет просто по тексту, это глупо. ИМХО.
Иногда на первый взгляд гвнокод может оказаться гениальным. И наоборот.

(64) + судить гвнокод или нет без истории развития и контекста принимаемых решений тоже глупо.

+(64) описанное относится к конкретному примеру. Однако, есть примеры, когда можно сразу сказать - это гвнокод.

(65) так я этом и говорю.

void MDObject::Destroy()
{
   if (Service()) {
       //to do: todo
       return;
   }

   bool result = true;
   List<MDObject>* itemList = new List<MDObject>();
   List<MDObject>* dependenceList = new List<MDObject>();
   List<MDObject>* ownerList = new List<MDObject>();
   PrepareDependenceAndItemList(itemList,dependenceList,ownerList);
   Iterator<MDObject>* ownerIterator = ownerList->CreateIterator();
   ownerIterator->Reset();
   CollectionManager<MDObject> ItemListManager(itemList);
   _foreach(MDObject* d, dependenceList) {
       if(!ItemListManager.Contains(d)) {
           //to do: todo
           result = false;
       }
       ownerIterator->Next();
   }
   delete ownerIterator;
   delete ownerList;
   delete dependenceList;
   delete itemList;
   if(result) {
       delete this;
   }
}

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

(69), в чем разница сам цепанешь таблицу или через точку напишешь и 1С создаст соединение с другой таблицей?