Базовый курс. Решение ДЗ №7
30.07.2011
комментариев 28
Представляем решение 7-го ДЗ.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись — напишите нам на e-mail поддержки.
а итог суммы я брал через Выборка.Док.Товары.Итог(“Сумма”), это сильно хуже чем у вас перебором складывать? лишний запрос к базе? тогда может в запросе иметь?
Да, это лишний запрос к БД.
А вот если обратиться к итогу от объекта, то лишнего запроса не будет, так как объект храниться в оперативной памяти.
Например, ЭтотОбъект.Товары.Итог(“Сумма”)
спасибо за все ответы. :) местами уже свет, местами еще туман :)
а бывает когда объект не целиком попадает в память? если я из журнала,
не входя в документ вызову его печать, он всегда целиком загрузится
в память? странно что вы не написали что в запросе оптимальней
считать итог тем более запрос все равно есть… в процедуре печати мы
имеем переданную ссылку и выборку из запроса. чтоб получить объект
из ссылки надо его вызывать целиком через Ссылка.ПолучитьОбъект() ?
чото каша в голове. А где взять ЭтотОбъект, находясь в МодулеМенеджера?
Просветы это хорошо.
Давайте по порядку.
Объект будет загружен в память только когда он будет явно получен. В частности это происходит в модуле объекта.
Если вы находитесь в модуле менеджера, то получать объект не рациональная и долгая операция. Правильнее получить нужные данные запросом.
>вы не написали что в запросе оптимальней считать итог тем более запрос все равно есть…
Речь идет об итогах. Разве мы их проходили в рамках задания №7.
>из ссылки надо его вызывать целиком через Ссылка.ПолучитьОбъект() ?
Да так, но как и писал выше это не рационально.
тогда еще раз уточню. в вашем решении дз 7 в для печати итоговой
суммы вы считаете ее в цикле по строкам.
это самый быстрый и оптимальный метод подсчета суммы?
Для данной задачи есть 3 способа решения:
1. Использование ИТОГИ … ПО ОБЩИЕ в запросе
2. Использование подсчета в цикле
3. Передача подсчитанного значения из модуля объекта.
Все три способа имеют сравнительную производительность.
То есть нельзя сказать, что один из них сильно лучше остальных. Если разница между ними и есть, то она незначительная.
Какой же из них самый быстрый? На этот вопрос может ответить только эксперимент.
Мне кажется, что №2 или №3. Эксперимент можете провести самостоятельно :)
ок. мне важно было знать что запрос не всегда самый
лучший вариант. до этого вроде везде звучало между
строк что любое обращение лучше через запрос…
ну или мне так казалось :)
Можно сказать так – если данные уже прочитаны в оперативную память, то запрос проиграет (это как раз работа в модуле объекта). Во всех остальных случаях для чтения данных из базы нужно применять запрос.
а случайно вдруг в 1с нет механизма просмотра
оперативной памяти? т.е. что в данный момент сидит
в кэше? для Если НЕ ЕстьВКэше(Объект.ссылка)
тогда ЗапросНаСервер().
просто пока по коду и контексту сложно понять
мы в объекте или он в нас….
Сидит ли объект в кэше или нет невозможно понять (заметьте речь о кеше, а не о непосредственном размещении объекта в оперативной памяти).
Упрощенно можно считать так:
1. В модуле объекта реквизиты объекта и табличные части “сидят” в памяти. Поэтому обращение к ним быстрое.
2. В остальных случаях эффективнее использовать запрос.
про упорядочивание…. “последний проведенный” получается можно понимать как последний Созданный или последний на оси Времени? МоментВремени выдает по какому-то внутреннему понятию крайний созданный документ, даже если его провели прошлым годом. Кстати если Упорядочить по Док.Ссылка то эффект тотже? А я понял что надо последний по оси времени. Тогда если в одну секунду будет толпа документов, то какой их них будет крайний? тогда надо по обоим сначала по Дате потом по Моменту времени?
>последний на оси Времени
Именно так и нужно понимать.
>выдает по какому-то внутреннему понятию крайний созданный документ, даже если его провели прошлым годом.
Не исключено, что это поведение будет изменено в других релизах платформы.
>Кстати если Упорядочить по Док.Ссылка то эффект тотже?
Порядок в этом случае не документирован, упорядочивание конечно будет.
> Тогда если в одну секунду будет толпа документов, то какой их них будет крайний?
Именно тот, у кого ссылка “больше”. Это документированное правило.
То есть упорядочивание по ссылке в рамках секунды это правильно.
Тот же результат даст и сортировка по моменту времени.
Вопрос по ДЗ.
1. Почему обязательно брать единицу измерения из подчиненного справочника а не из реквизита номенклатуры?
2. Вопрос по запросам.
В решении ДЗ при поиске документа первоначально был вложенный запрос и проверка на то что документ входит в это множество. Не лучше ли сделать соединение с этим запросом? То есть по сути вопрос такой – по производительности работает одинаково inner join и in ? Что лучше использовать?
>Почему обязательно брать единицу измерения из подчиненного справочника а не из реквизита номенклатуры?
Видимо вопрос в том, почему используется справочник ЕдиницыНоменклатуры, а не КлассификаторЕдиницИзмерения?
Если да, то дело вот в чем – в классификаторе представлены все возможные единицы, для всех номенклатур.
А в ЕдиницахНоменклатуры создаются только те, которые имеют смысл для данного товара, кроме этого здесь же определяются необходимые дополнительные свойства. В нашем случае это Коэффициент, также могут указываться весо-габаритные характеристики.
>В решении ДЗ при поиске документа первоначально был вложенный запрос и проверка на то что документ входит в это множество
Пока не могу вспомнить, где использовался подобный запрос. Уточните место в конфигурации, тогда смогу дать ответ на вопрос.
Место в конфигурации – ввод на основании справочника Контрагенты
документа ПоступлениеТовара или РеализацияТовара.
Например:
Запрос 1
<code>
ВЫБРАТЬ
Номенклатура,
Качество,
ЕдиницаИзмерения,
Количество,
Цена,
Сумма
ИЗ
Документ.ПоступлениеТоваров.Товары КАК ДокументТовары
ГДЕ
ДокументТовары.Ссылка В (ВЫБРАТЬ
Первые 1 Ссылка
ИЗ
Документ.ПоступлениеТоваров Документ
Где
Документ.Проведен
И Документ.Контрагент = &Контрагент
УПОРЯДОЧИТЬ ПО
Документ.Дата УБЫВ, Документ.Ссылка УБЫВ)
</code>
Запрос2
<code>
ВЫБРАТЬ
Номенклатура,
СтепеньБрака,
ЕдиницаИзмерения,
Количество,
Цена,
Сумма
ИЗ
Документ.ПоступлениеТоваров.Товары КАК ДокументТовары
ВНУТРЕННЕЕ СОЕДИНЕНИЕ
(ВЫБРАТЬ
Первые 1 Ссылка
ИЗ
Документ.ПоступлениеТоваров Документ
Где
Документ.Проведен
И Документ.Контрагент = &Контрагент
УПОРЯДОЧИТЬ ПО
Документ.Дата УБЫВ, Документ.Ссылка УБЫВ
) как Документ
По
ДокументТовары.Ссылка = Документ.Ссылка
В Запрос1 используется В.
В запросе2 используется Внутренее соединение.
Какой вариант работает более производительней?
Теперь вопрос понятен.
В данном конкретном случае разницы не будет, так как вложенный запрос содержит 0 или 1 строку.
А в общем случае правильнее использовать соединения.
Более того, вложенный запрос нужно положить во временную таблицу.
Спасибо
И по ошибке платформы вопрос, в чем ошибка конкретно заключается? То есть я понял, что в том конкретном случае запрос неправильно выполняется, но общий вид ошибки не уловил. Не верно выполняется сортировка по моменту времени во всех вложенных подзапросах? Или там что-то более общее в сортировках вообще?
Дальше, спасибо за редактирование запроса через СтрЗаменить. Это восторг просто:) Но в задании написано, что продажи пойдут со скидками в зависимости от брака?! У меня из-за этого табличные части не одинаковы, в реализацию я, перестаравшись, записал %скидки. Хотя сложностей все равно особых нет, можно одну строчку на две менять:)
Вобщем как всегда спасибо за море удовольствия, жаль так мало времени на курс:)
> Не верно выполняется сортировка по моменту времени во всех вложенных подзапросах
Да, именно так.
Спасибо за обратную связь, успехов обучении! :)
Вопрос по ценам. Раньше работал в другой системе, там цены (учетные) предпочитали хранить с большим количеством знаков после запятой, чтобы не было проблем с погрешностями округления в суммах. В некоторых пересчетах там это играло. 2 знака после запятой в цене – это умолчальный стандарт? Просто при ценах в евро это может играть приличную роль, там может цена меньше евроцента быть у всякой фурнитуры, например.
>2 знака после запятой в цене – это умолчальный стандарт?
Да, по крайней мере в типовых решениях фирмы 1С.
Евгений, скажите пожалуйста, а не будет ли точнее, если в запросе, который определяет единицу измерения ном-ры, соотв-щую базовой ЕИ добавить условие Коэффициент = 1?
Ведь если коэффициент будет другой – это уже другая ЕИ.
Заранее спасибо.
Оставить только это условие нельзя.
Так как может быть две разных единицы у которых коэффициент = 1.
Возможно имеет смысл поставить это дополнительное условие к уже имеющимся.
:) я и имела ввиду добавить это условие, неточно выразилась
Просто, когда я делала ДЗ, то условия сделала такие же как и у Вас в решении, но еще Коэффициент = 1.
Думаю, что это условие избыточное.
Если в системе есть две единицы для номенклатуры, которые претендуют на базовую, то это ошибка логики системы (по крайней мере в нашем случае).
С тем же успехом может быть две базовых единицы с коэффициентом 1.
Мне кажется, мы друг друга не понимаем, по разному рассуждаем.
Я рассуждаю так. Есть справочник ЕдиницыИзмеренияНоменклатуры в котором хранится ссылка на ЕИ по классификатору и коэффициент пересчета в эту ЕИ по классификатору (базовую ЕИ).
При создании новой номенклатуры мы создаем в справочнике ЕдиницыИзмеренияНоменклатуры ЕИ, соотв-щую ЕИ по классификатору с коэффициентом 1 (например, штука: базовая единица – штука, коэффициент = 1 )
Впоследствии, я могу добавить еще одну ЕИ – упаковка (базовая ЕИ – штука, коэффициент = 10).
Как я понимаю, мы же все-таки под базовой понимаем ту ЕИ, что с коэффициентом 1 и подставлять должны именно ее.
Ну хотя, может я слишком много думаю :))))
Со мной бывает :)
Логика в моем решении иная.
В реквизите номенклатуры указывается ссылка на ЕИ по классификатору, это и есть базовая единица. Именно единицу с таким ОКЕИ и нужно найти в справочнике “ЕдиницыИзмеренияНоменклатуры”.
Исходя из этого и написана такая проверка.
ок, спасибо