Какой регистр с запросом к нему более подходит для решения задачи
Задача: необходимо хранить информацию о периодичности действия скидок для контрагентов, и в документе "Реализация товаров и услуг" получать, действует ли скидка в указанный период или нет. Запись в регистр происходит документом "Установка скидок", в котором указывается начало и окончание действия скидки, Скидка - справочник "Скидки" и Контрагент.
Способы решения:
1. Периодчиский регистр сведений.
Измерения: Скидка, Контрагент.
Ресурсы: нет.
Реквизиты: ДатаОкончания
ДатаНачала документа "Установка скидок" записывается в Период регистра сведений, ДатаОкончания в одноименный реквизит.
Запрос в документе "Реализация товаров и услуг":
То есть отбор по периоду происходит таким образом - "СрезПоследних(&Дата" - отбор по выше даты начала, "&Дата <= КОНЕЦПЕРИОДА(ДатаОкончания, ДЕНЬ)" - отбор по меньше даты окончания.
2. Периодический регистр накопления "Остатки"
Измерения: Скидка, Контрагент.
Ресурсы: Количество.
Документом "Установка скидок" производится 2 записи в регистр, первая - приход на дату начала, вторая расход на дату окончания, количество всегда 1.
Запрос в документе "Реализация товаров и услуг":
То есть в период действия скидки остаток должен быть 1, в период до и после остаток должен быть 0, и проверяя остаток мы получаем дейсвует скидка, или нет.
Оба варианта являются рабочими и решают задачу, выбирая между ними я выбрал второй. Но хотелось бы услышать критику.
Способы решения:
1. Периодчиский регистр сведений.
Измерения: Скидка, Контрагент.
Ресурсы: нет.
Реквизиты: ДатаОкончания
ДатаНачала документа "Установка скидок" записывается в Период регистра сведений, ДатаОкончания в одноименный реквизит.
Запрос в документе "Реализация товаров и услуг":
Запрос.Текст = "ВЫБРАТЬ
| ПериодДействияСкидокСрезПоследних.Скидка
|ИЗ
| РегистрСведений.ПериодДействияСкидок.СрезПоследних(
| &Дата,
| Контрагент = &Контрагент И Скидка = &Скидка
| И &Дата <= КОНЕЦПЕРИОДА(ДатаОкончания, ДЕНЬ)) КАК ПериодДействияСкидокСрезПоследних";
Если Не Запрос.Выполнить().Пустой() Тогда
//скидка действует ПоказатьТо есть отбор по периоду происходит таким образом - "СрезПоследних(&Дата" - отбор по выше даты начала, "&Дата <= КОНЕЦПЕРИОДА(ДатаОкончания, ДЕНЬ)" - отбор по меньше даты окончания.
2. Периодический регистр накопления "Остатки"
Измерения: Скидка, Контрагент.
Ресурсы: Количество.
Документом "Установка скидок" производится 2 записи в регистр, первая - приход на дату начала, вторая расход на дату окончания, количество всегда 1.
Запрос в документе "Реализация товаров и услуг":
Запрос.Текст = "ВЫБРАТЬ
| ПериодДействияСкидокОстатки.Скидка
|ИЗ
| РегистрНакопления.ПериодДействияСкидок.Остатки(
| &Дата,
| Контрагент = &Контрагент
| И Скидка = &Скидка) КАК ПериодДействияСкидокОстатки";
Если Не Запрос.Выполнить().Пустой() Тогда
//скидка действует ПоказатьТо есть в период действия скидки остаток должен быть 1, в период до и после остаток должен быть 0, и проверяя остаток мы получаем дейсвует скидка, или нет.
Оба варианта являются рабочими и решают задачу, выбирая между ними я выбрал второй. Но хотелось бы услышать критику.
По теме из базы знаний
- Решение детективных задач
- PMI, Scrum и Kanban – как работать с содержанием (scope) в каждом из подходов и где границы его применимости
- Начните уже использовать хранилище запросов
- История одного админа в мире 1С. Как поиски причины тормозов 1С привели к созданию нового продукта
- Применение 1С:Аналитики и Дата акселератора, или Как получить в 1С прозрачность и скорость обработки данных для прямого доступа и контроля руководителя
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
поскольку задача звучит вот так - то логично использованием регистра сведений. Альтернативный вариант с РН замечателен и показывает, что автор способен мыслить и не шаблонами тоже :) (прошу прощения за менторский тон ))) ) По факту, данный алгоритм можно написать через что угодно - и через регистры и через справочники.
Если по производительности сильных различий нет, смотрите дальше - на дальнейшее масштабирование кода, удобство обслуживания кода, на то каким образом с этим будут работать люди после вас (в ваше отсутствие) и насколько быстро они "въедут" в эту фишку и т.п. Часто это оказывается важнее непосредственно алгоритма и производительности.
Istur пишет:
Задача: необходимо хранить информацию о периодичности действия скидок для контрагентов
Задача: необходимо хранить информацию о периодичности действия скидок для контрагентов
поскольку задача звучит вот так - то логично использованием регистра сведений. Альтернативный вариант с РН замечателен и показывает, что автор способен мыслить и не шаблонами тоже :) (прошу прощения за менторский тон ))) ) По факту, данный алгоритм можно написать через что угодно - и через регистры и через справочники.
Если по производительности сильных различий нет, смотрите дальше - на дальнейшее масштабирование кода, удобство обслуживания кода, на то каким образом с этим будут работать люди после вас (в ваше отсутствие) и насколько быстро они "въедут" в эту фишку и т.п. Часто это оказывается важнее непосредственно алгоритма и производительности.
На данных приближенных к реальным получил такие предварительные результаты.
По запросу в (1) время выполнения 0 мс
По запросу в (3) время выполнения 0 мс
Это на файловой версии. Не думаю, что на SQL результаты будут сильно отличаться от этих.
Разница в отладчике конечно же ловится, но совсем незначительная и играет в обе стороны. Думаю, её можно списать на погрешность измерений.
Теперь почему такие результаты.
В реальных условиях скидок много не дают. Точнее так. Не дают каждую неделю 2000 контрагентам в течении 12 лет по 10 разных скидок.
Думаю, нужно проверять не на реальных данных, а на избыточных, тогда можно будет поймать разницу.
Сделаю базу:
Контрагентов - 2000
Скидок - 10
Скидки назначаются все всем еженедельно с 01.01.2000 по текущую неделю.
Для каждого второго контрагента на текущую неделю скидки не назначаются.
Так можно проверить работу со значениями в результатах Истина и Ложь.
(59) Могу добавить и этот вариант в учасники.
Пока интрига сохраняется... :)
По запросу в (1) время выполнения 0 мс
По запросу в (3) время выполнения 0 мс
Это на файловой версии. Не думаю, что на SQL результаты будут сильно отличаться от этих.
Разница в отладчике конечно же ловится, но совсем незначительная и играет в обе стороны. Думаю, её можно списать на погрешность измерений.
Теперь почему такие результаты.
В реальных условиях скидок много не дают. Точнее так. Не дают каждую неделю 2000 контрагентам в течении 12 лет по 10 разных скидок.
Думаю, нужно проверять не на реальных данных, а на избыточных, тогда можно будет поймать разницу.
Сделаю базу:
Контрагентов - 2000
Скидок - 10
Скидки назначаются все всем еженедельно с 01.01.2000 по текущую неделю.
Для каждого второго контрагента на текущую неделю скидки не назначаются.
Так можно проверить работу со значениями в результатах Истина и Ложь.
(59) Могу добавить и этот вариант в учасники.
Пока интрига сохраняется... :)
(2) Без этих условий выполнение невозможно, так что хочешь, не хочешь, а накладывать условия надо.
(3) С данной мыслью можно согласиться. Отбор по индексируемым измерениям происходит быстро, а вот отбор по не индексируемому реквизиту будет происходить медленно. А в итоге реально будет 1 или 2 записи, и можно будет проверить на сравнение. Да, я согласен, спасибо.
(5) Спасибо за эти мысли, с вашим мнением можно согласиться..
(6) Логичная мысль, но в таблице будет такое ничтожное количество записей, что все отборы будут работать одинаково быстро.
(7) Да, согласен с вами. Про итоги я забыл, а они тоже занимают некоторый размер. Про запрос - полностью не согласен. 1. Условия наложены через "ГДЕ". Так не нужно. Точнее вы делаете запрос к реальной таблице, а не к виртуальной. 2. Измерение ДатаНачала - излишне, подойдет типовой реквизит Период. 3. ДатаОкончание. Почему ресурс, это реквизит. В общем если бы такой запрос вы сделали на экзамене по платформе, то это или минус 2 балла, или сразу на пересдачу.
(3) С данной мыслью можно согласиться. Отбор по индексируемым измерениям происходит быстро, а вот отбор по не индексируемому реквизиту будет происходить медленно. А в итоге реально будет 1 или 2 записи, и можно будет проверить на сравнение. Да, я согласен, спасибо.
(5) Спасибо за эти мысли, с вашим мнением можно согласиться..
(6) Логичная мысль, но в таблице будет такое ничтожное количество записей, что все отборы будут работать одинаково быстро.
(7) Да, согласен с вами. Про итоги я забыл, а они тоже занимают некоторый размер. Про запрос - полностью не согласен. 1. Условия наложены через "ГДЕ". Так не нужно. Точнее вы делаете запрос к реальной таблице, а не к виртуальной. 2. Измерение ДатаНачала - излишне, подойдет типовой реквизит Период. 3. ДатаОкончание. Почему ресурс, это реквизит. В общем если бы такой запрос вы сделали на экзамене по платформе, то это или минус 2 балла, или сразу на пересдачу.
(8) Вот и не правда ваша. За экзамен у меня 5+ и сдал я его, как бы это сказать, с блеском. Причем все выборки данных были построены только на запросах.
Я не могу обратиться к виртуальной таблице "ввиду отсутствия таковой (с)". У непериодического регистра сведений нет виртуальных таблиц. Соотвественно:
1. Условия наложены через "ГДЕ". Так нужно
2. Измерение ДатаНачала - нужно, т.к. не подойдет типовой реквизит Период опять же ввиду отсутствия
3. ДатаОкончание. Почему ресурс, это реквизит. Может быть. Хотя в данном случае не вижу принципиальной разницы ни в запросах, ни в интерфейсах.
Я не могу обратиться к виртуальной таблице "ввиду отсутствия таковой (с)". У непериодического регистра сведений нет виртуальных таблиц. Соотвественно:
1. Условия наложены через "ГДЕ". Так нужно
2. Измерение ДатаНачала - нужно, т.к. не подойдет типовой реквизит Период опять же ввиду отсутствия
3. ДатаОкончание. Почему ресурс, это реквизит. Может быть. Хотя в данном случае не вижу принципиальной разницы ни в запросах, ни в интерфейсах.
(9) - я не хочу сказать, что вы некомпетентный специалист, совсем нет. просто я озвучиваю требования экзамена, а одно из них - пользоваться виртуальными таблицами при возможности их использования и если подлавливают на этом моменте, то снижают на 2 балла. Это факт. "Не подойдет типовой реквизит ввиду отсутствия" - ну почему же. Достаточно просто сделать регистр сведений периодическим, и данный реквизит появится. И появится виртуальная таблица)
3. ДатаОкончания - ну принципиальной разницы в запросах и интерфейсах нет, а в правильности построения базы данных есть.
3. ДатаОкончания - ну принципиальной разницы в запросах и интерфейсах нет, а в правильности построения базы данных есть.
(10) "И появится виртуальная таблица" А зачем? Что это даст в данном случае? Более запутанный код? Уверен, что на реальных данных мой запрос отработает быстрее и при трансляции будет проще.
"3. ДатаОкончания - ну принципиальной разницы в запросах и интерфейсах нет, а в правильности построения базы данных есть." Хорошо. В чем разница?
"3. ДатаОкончания - ну принципиальной разницы в запросах и интерфейсах нет, а в правильности построения базы данных есть." Хорошо. В чем разница?
(13) Нет. Как я представляю матчасть, в этом случае у регистра создаются виртуальные таблицы и идет обращение к ним, и обращение более быстрое. И в пользу данного решения говорит то, что 1с при решении аналогичной задачи пошло таким же образом, периодический регистр сведений с реквизитом ДатаОкончания. Это регистр "СкидкиНаценкиНоменклатуры" УПП. Так что с тем, что быстрее я не согласен, быстрее именно олжна быть виртуальная таблица. Но версия что тогда код становится проще мне нравится, потому что усложнять то, что можно сделать проще не нужно. Просто я хочу следовать стандартам 1с, и делать как правильно, как они предписывают и рекомендуют.
(14) Ну данную нелепость примени фирма 1с.. Значит это не просто так.
(14) Ну данную нелепость примени фирма 1с.. Значит это не просто так.
(16) Ты исходишь из общих соображений и типовых решений. Не всегда убедительно.
Может быть, здесь не к месту , но совсем недавно Алекс убедительно опроверг все типовые решения по вопросу :
как суммировать ячейки в табл.документе ? Оказалось , что "Попытка" в процедуре подсчета не нужна.
Это я к тому , общие соображения и ссылки на типовые решения работают невсегда.
Может быть, здесь не к месту , но совсем недавно Алекс убедительно опроверг все типовые решения по вопросу :
как суммировать ячейки в табл.документе ? Оказалось , что "Попытка" в процедуре подсчета не нужна.
Это я к тому , общие соображения и ссылки на типовые решения работают невсегда.
(18) Я исхожу из мысли, что пока не доказано обратное, мысль верна. И раз так поступила фирма 1с, то значит данное решение является наилучшим. Но если кто-то аргументированно докажет, что нет, можно сделать лучше, то я восприму эти слова. Но то что где-то фирма 1с ошиблась для меня доводом не является. Собственно кстати это и есть цель поста, путем общения с коллегами установить какой из уже 3 вариантов реализации решения является самым оптимальным.
(19) Строго говоря , я прицепился лишь к твоим словам , что вариант Алекса заслуживает двойки на экзамене.
А вот какой вариант лучше и эффективнее твой или Алекса - без тестирования вряд ли что-то можно сказать.
Выглядит вариант Алекса поэкономней, но много раз убеждался как очевидное в запросах становилось неэффективным при тестировании.
А вот какой вариант лучше и эффективнее твой или Алекса - без тестирования вряд ли что-то можно сказать.
Выглядит вариант Алекса поэкономней, но много раз убеждался как очевидное в запросах становилось неэффективным при тестировании.
(10) Скажи , а почему обращение к физической таблице хуже чем к виртуальной ?
Ведь обращаясь к виртуальной таблице ты делаешь запрос к запросу.
Искусственно создавать периодический регистр только для того чтобы обратиться к виртуальной таблице -
это нелепость , на мой скромный взгляд.
Ведь обращаясь к виртуальной таблице ты делаешь запрос к запросу.
Искусственно создавать периодический регистр только для того чтобы обратиться к виртуальной таблице -
это нелепость , на мой скромный взгляд.
(10) Где и кто тебе сказал (ссылку!) что нужно искусственно стремиться к обращениям к виртуальной таблице?
Обращение к виртуальной таблице даёт выигрыш по сравнению с обращением к физической таблице в тех регистрах
где предусмотрены вирт.таблицы.
Если же у регистра нет вирт.таблицы , то зачем огород городить ?
Обращение к виртуальной таблице даёт выигрыш по сравнению с обращением к физической таблице в тех регистрах
где предусмотрены вирт.таблицы.
Если же у регистра нет вирт.таблицы , то зачем огород городить ?
(15) Требования к экзамену по платформе 1с, оттуда. У регистра накопления виртуальные таблицы итогов есть. Насчет регистра сведений я не знаю, но согласно наличию СрезПоследних и СрезПервых, то у него есть тоже. Но тут могу ошибаться, хотелось бы чтобы кто-то ответил точно.
(8) Кхы..кхы..
Ты с размаху и сгоряча упустил , что у Алекса непериодический регистр ?
Хм.. и тогда все три твои пункта - недоразумение.
Про запрос - полностью не согласен. 1. Условия наложены через "ГДЕ". Так не нужно. Точнее вы делаете запрос к реальной таблице, а не к виртуальной. 2. Измерение ДатаНачала - излишне, подойдет типовой реквизит Период. 3. ДатаОкончание. Почему ресурс, это реквизит. В общем если бы такой запрос вы сделали на экзамене по платформе, то это или минус 2 балла, или сразу на пересдачу.
Ты с размаху и сгоряча упустил , что у Алекса непериодический регистр ?
Хм.. и тогда все три твои пункта - недоразумение.
(11) Я в корне не согласен, что данный регистр непереодический. Еще раз. Его решение тоже решает задачу, можно сказать, что это третий вариант. Но с данным решением, непереодическим регистром сведений я не согласен, когда можно сделать периодическим и использовать виртуальные таблицы.
Странно, что никто не обратил внимание на то, что варианты из (3) и (7) нельзя сравнивать, как и варианты 1 и 2 у автора, которые (1 и 2) оба не верные! Верный только (3)!
Потому что они отвечают на разные вопросы.
(3) отвечает на вопрос: действует ли на заданную дату скидка,установленная последней (с точки зрения той же даты).
(7) и 2 отвечает на вопрос: устанавливалась ли когда-либо скидка, период действия которой включает заданную дату?
Отличия возникают тогда, когда периоды действия скидки, установленной разными документами, перекрываются. В вариантах (7) и 2 просто нельзя будет отменить ранее установленную скидку, период действия которой - "до второго пришествия".
Поэтому в типовых 1С и применяется (3). Кстати, в варианте (3) окончание скидки - ресурс (а не реквизит)! Иначе его не будет в виртуальном регистре.
Из этого следует, что вариант 1 у автора - тоже не верный! Потому, что отбираются последние незакончившиеся скидки. А на практике мы можем позже решить,что скидка должна действовать меньше!
Теперь о (21): Можно ли для ускорения переносить реквизит "Период" в измерение? Насколько эквивалентны периодический регистр (а) и регистр с измерением период (б) в элементарных задачах?
Эксперименты (не ручаюсь за то,что они были исчерпывающими) показали,что установка индекса по полю "период" не ускоряет поиск по условию "<" (проверки неравенства) в варианте (б). Поэтому кажется, что виртуальный регистр должен выиграть за счет того,что основан на специального вида индексе по полю "период", оптимизированном именно для отбора по условию "<".
С интересом ознакомился бы с более глубокими исследованиями на эту тему. Это могло быть либо тестирование, либо анализ соответствующих SQL-запросов.
Потому что они отвечают на разные вопросы.
(3) отвечает на вопрос: действует ли на заданную дату скидка,установленная последней (с точки зрения той же даты).
(7) и 2 отвечает на вопрос: устанавливалась ли когда-либо скидка, период действия которой включает заданную дату?
Отличия возникают тогда, когда периоды действия скидки, установленной разными документами, перекрываются. В вариантах (7) и 2 просто нельзя будет отменить ранее установленную скидку, период действия которой - "до второго пришествия".
Поэтому в типовых 1С и применяется (3). Кстати, в варианте (3) окончание скидки - ресурс (а не реквизит)! Иначе его не будет в виртуальном регистре.
Из этого следует, что вариант 1 у автора - тоже не верный! Потому, что отбираются последние незакончившиеся скидки. А на практике мы можем позже решить,что скидка должна действовать меньше!
Теперь о (21): Можно ли для ускорения переносить реквизит "Период" в измерение? Насколько эквивалентны периодический регистр (а) и регистр с измерением период (б) в элементарных задачах?
Эксперименты (не ручаюсь за то,что они были исчерпывающими) показали,что установка индекса по полю "период" не ускоряет поиск по условию "<" (проверки неравенства) в варианте (б). Поэтому кажется, что виртуальный регистр должен выиграть за счет того,что основан на специального вида индексе по полю "период", оптимизированном именно для отбора по условию "<".
С интересом ознакомился бы с более глубокими исследованиями на эту тему. Это могло быть либо тестирование, либо анализ соответствующих SQL-запросов.
(44) Безусловно радует такой вдумчивый и развернутый ответ, значит данная тема представляет интерес. Но больше он заслуживает критики, чем благодарности. и 1 и 2 мои варианта являются верными.
А вот комментарий к (21) я прочел с интересом.
(7) и 2 отвечает на вопрос: устанавливалась ли когда-либо скидка, период действия которой включает заданную дату?
верно. нам нужно ответить собственно на этот вопрос, действует ли скидка в указанный период, или нет. И все запросы данную задачу решают. Отличия возникают тогда, когда периоды действия скидки, установленной разными документами, перекрываются.
А вот уже незнание мат.части. Вы подходите к решению задачи как программист, увидевший интересную задачу и решающий ее в отрыве от реальности. Но задача собственно прикладная. И ситуация, когда скидка одним документов установлена с 1 по 30 июня, а другим с 15 июня по 15 июля по определению невозможна. В документ "Установка скидок" вставляется проверка, чтобы периоды скидок были непересекающимися. поэтому скидка может начаться только после того, как закончится предыдущая. Ну и плюс вы как-то совсем не уважаете пользователей. Кто-то захотел - создал вот скидку на такие числа, кто-то на другие. Угу. Скидки создаются коммерческим отделом после анализа и подписываются потом финансовым директором. Отделы и руководители могут быть другими, произвольными, но факт остается фактом, данные документы не от балды создаются. Поэтому тут будет двойная проверка, сначала на уровне планирования скидок, на бумаге, ну а потом проверки на уровне 1с. Кстати, в варианте (3) окончание скидки - ресурс (а не реквизит)! Иначе его не будет в виртуальном регистре.
Нуну. Реквизиты присутствуют в виртуальных таблицах. Я даже специально отрыл параметры виртуальной таблицы, вдруг ошибаюсь. Но нет, ошибаетесь вы. ДатаОкончания - реквизит, доступный там. И смотрите регистр "Скидки наценки номенклатуры", то что такой вариант использует 1с, уже говорит о многом.
А вот комментарий к (21) я прочел с интересом.
(45)
Ну а то, что периоды действия скидки не могут перекрываться у Вас в задании не написано. Это дополнительное и вовсе не очевидное условие задачи (что бы Вы теперь не говорили - Тем более,что вариант 3 работает и так).
При таком условии быстрее всего будет работать вариант "4" с созданием двух записей в периодическом регистре сведений: на дату установки и на дату отмены скидки. То есть измерения: Контрагент, Скидка и булевый ресурс: Действует. Первая запись: Действует =Истина,а вторая: Действует = Ложь.
Так что остаюсь при своем мнении: без дополнительных проверок при записи в регистры варианты 1 и 2 не верны. На будущее: в таких вопросах постановка задачи должна быть исчерпывающей - недостающие условия разные люди склонны домысливать по-разному.
Реквизиты присутствуют в виртуальных таблицах (регистров сведений).
Да, это так (посмотрел в конструкторе) - тут я формально не прав. Все же по-сути ДатаОкончания ближе к ресурсу, поскольку характеризует состояние скидки после изменения, а не само изменение (с моей точки зрения).
Ну а то, что периоды действия скидки не могут перекрываться у Вас в задании не написано. Это дополнительное и вовсе не очевидное условие задачи (что бы Вы теперь не говорили - Тем более,что вариант 3 работает и так).
При таком условии быстрее всего будет работать вариант "4" с созданием двух записей в периодическом регистре сведений: на дату установки и на дату отмены скидки. То есть измерения: Контрагент, Скидка и булевый ресурс: Действует. Первая запись: Действует =Истина,а вторая: Действует = Ложь.
Так что остаюсь при своем мнении: без дополнительных проверок при записи в регистры варианты 1 и 2 не верны. На будущее: в таких вопросах постановка задачи должна быть исчерпывающей - недостающие условия разные люди склонны домысливать по-разному.
(47) Ну просто лично для меня данное условие очевидно. В том что я его не огласил возможна есть моя вина, но другие коллеги кажется поняли все верно. В любом случае это не важно и уход от темы разговора. То что мои варианты не совсем подходят к условиям, созданными вами - есть такое. Но еще раз, условия другие и как подходят для решения других задач, есть тема непонятная и ненужная. Разные задачи решаются разными способами. Насчет вашего решения, 2 записи в регистре сведений - по сути это созвучно с моим вторым решением, 2 записи в регистре накопления, приход и расход. Но и то и другое мне кажется не самым лучшим, лучше регистр сведений с 1 записью. Тем более запрос по регистру сведений с 2 записями будет менее оптимален, чем с 1 записью, потому что там в параметрах я наложу все условия, и на дату начала, и на дату окончания, а у вас придется делать сложнее. И если вы защищаете вот это свое решение, то запрос в студию) Цель запроса думаю вы поняли, понять действует ли скидка на указанную дату или нет.
(49)
Мне кажется, Вы спорите зря.
(0) - Вы задали вопрос, какой вариант лучше "1" или "2". Вам ответили "1+" = (3). Вы согласились.
Я также считаю этот вариант лучшим. При этом я этот выбор обосновал:
метод простой, быстрый и, главное - работает в более широком диапазоне условий, без блокировок (об этом ниже).
Попутно я заметил, что 1, 2 и, кстати, (7) в данной задаче вообще не годятся.
Еще раз объясню, почему:
На практике лучше допустить перекрытие периодов скидок, записанных документами.
В ином случае, чтобы прекратить действие скидки, записанной январским документом, действующей до октября,
Вам придется в сентябре заходить в этот январский документ и менять его - устанавливать более раннее окончание скидки.
То есть заходить в закрытый период. Также, чтобы узнать, кто и когда это изменил, потребуется версионирование.
Зачем, если можно ввести новый документ сегодняшней датой с другим ответственным,
в котором изменить период окончания скидки?
Также, чтобы продлить действие скидки, Вам придется пристыковывать ее к окончанию очередного периода,
рассчитывая на его неизменность.
Кроме того, чтобы при проведении проверять пересечение периодов, Вам перед записью придется делать запрос чтения к тому же регистру.
А это уже источник блокировок: контрагентов может быть не одна сотня, скидки могут назначаться одновременно.
А если забыть в запросе "для изменения" - получите дедлок.
Извините за занудство - больно видеть, как Вы наступаете на грабли.
Мне кажется, Вы спорите зря.
(0) - Вы задали вопрос, какой вариант лучше "1" или "2". Вам ответили "1+" = (3). Вы согласились.
Я также считаю этот вариант лучшим. При этом я этот выбор обосновал:
метод простой, быстрый и, главное - работает в более широком диапазоне условий, без блокировок (об этом ниже).
Попутно я заметил, что 1, 2 и, кстати, (7) в данной задаче вообще не годятся.
Еще раз объясню, почему:
На практике лучше допустить перекрытие периодов скидок, записанных документами.
В ином случае, чтобы прекратить действие скидки, записанной январским документом, действующей до октября,
Вам придется в сентябре заходить в этот январский документ и менять его - устанавливать более раннее окончание скидки.
То есть заходить в закрытый период. Также, чтобы узнать, кто и когда это изменил, потребуется версионирование.
Зачем, если можно ввести новый документ сегодняшней датой с другим ответственным,
в котором изменить период окончания скидки?
Также, чтобы продлить действие скидки, Вам придется пристыковывать ее к окончанию очередного периода,
рассчитывая на его неизменность.
Кроме того, чтобы при проведении проверять пересечение периодов, Вам перед записью придется делать запрос чтения к тому же регистру.
А это уже источник блокировок: контрагентов может быть не одна сотня, скидки могут назначаться одновременно.
А если забыть в запросе "для изменения" - получите дедлок.
Извините за занудство - больно видеть, как Вы наступаете на грабли.
(55) У вас какая-то мания делать то, что не просят, и убеждать в том, где с вами не спорят. Еще раз условия - периоды непересекающиеся! Не надо мне расписывать то, о чем я вообще не спрашиваю. Почему то вы сами додумываете за меня мою позицию, сами со мной спорите. Возникает только вопрос, зачем я тут. Я не говорил вам о том, что считаю нужным изменять старые документы, я говорю о том, что для чистоты эксперимента мы признает условие, что они всегда непересакаются! Если что-то непонятно не незачем самому додумывать, спрашивайте. Скидки здесь не более чем пример. Хотя конечно можно и сформулировать решение задачи скидок, если скидки могут изменяться, как сделать это лучше. Но не хочется. И кстати, фразы:
(59) Ну как, включаем эти 2 ваших варианта в забег?)
(64) Поставлю конечно, так интереснее! Но 100 баксов многовато однако!
(63) Смещай ограничение пожалуйста до конца завтрашнего дня по МСК, надо еще включить ildarovich с его вариантами, если созреет. 4-5 лошадок всяк инетреснее, чем 2)) И может еще кто что придумает)
(65) Да, безусловно данных надо избыточно. Буду ждать окончания теста)))\
(64) Аа, это не баксы а некие StartMoney. а что это такое и как соотносится с реальной валютой? И сотню не могу в любом случае, у меня написано, что их 28.
Извините за занудство - больно видеть, как Вы наступаете на грабли.
оставьте себе, мне этакие комментаторы, поучающие о том, о чем их и не спрашивают не нужны. а занудство да, вам присуще. ну уже бесит реально. вот каждый раз когда я что-то публикую или пишу на форуме, вот появляется непонятный человек с непонятными комментариями не по теме. В общем вы предложили вариант с 2 записями в регистре сведений и вариант с 1 записью регистра сведений, но использованием не запроса, а методов менеджера регистра сведений. Если готовы, то их можно тестить и включать в шорт-лист в наш забег, давайте, любой предложенный вариант имеет право на участие и внимание к нему)) А вот длинные сообщения не по теме больше писать не стоит.
(59) Ну как, включаем эти 2 ваших варианта в забег?)
(64) Поставлю конечно, так интереснее! Но 100 баксов многовато однако!
(63) Смещай ограничение пожалуйста до конца завтрашнего дня по МСК, надо еще включить ildarovich с его вариантами, если созреет. 4-5 лошадок всяк инетреснее, чем 2)) И может еще кто что придумает)
(65) Да, безусловно данных надо избыточно. Буду ждать окончания теста)))\
(64) Аа, это не баксы а некие StartMoney. а что это такое и как соотносится с реальной валютой? И сотню не могу в любом случае, у меня написано, что их 28.
(67) Мне жалко моего 1 $m. Чувствую - надуете.
Вы еще раз договоритесь. Четко и ясно опубликуйте :
1. Вариант Алекса. Структура регистра. КОличество записей. Тестируемый запрос.
2. Вариант Станислава.Структура регистра. КОличество записей. Тестируемый запрос.
Чтобы потом не было разночтений.
P.S. Не жмись. 100 $m -нормально.
Вы еще раз договоритесь. Четко и ясно опубликуйте :
1. Вариант Алекса. Структура регистра. КОличество записей. Тестируемый запрос.
2. Вариант Станислава.Структура регистра. КОличество записей. Тестируемый запрос.
Чтобы потом не было разночтений.
P.S. Не жмись. 100 $m -нормально.
(67) Не надуем)) Хорошо, вечером я отпишусь по структуре. Так что такое эти StartMoney?? нигде на сайте не могу найти описания. Тыкните битте.
P.S. Так яж не могу ставить того, что у меня нет. У меня тока 28.90. ОО. прикольно!! уже 29.50. Значит эта фишка дается за сообщение или пребывание на сайте. Осталось только узнать как соотносится с реальными деньгами)
P.S. Так яж не могу ставить того, что у меня нет. У меня тока 28.90. ОО. прикольно!! уже 29.50. Значит эта фишка дается за сообщение или пребывание на сайте. Осталось только узнать как соотносится с реальными деньгами)
(76) Итак, мои результаты:
- файловая база в быстром терминальном сервере;
- 1000 контрагентов;
- 10 скидок;
- 12 назначений скидок;
- среднее время между назначениями скидок - 60 дней;
- среднее время действия скидки - 30 дней (именно так, хотя не принципиально!);
- интервалы случайные (экспоненциальный закон);
- проверяется скидка на "сегодня" (генерация интервалов идет вглубь),
- 10 прогонов на каждого контрагента+скидку - всего 100000 прогонов.
На первом месте с результатом 460 микросекунд на проверку - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания через метод менеджера ПолучитьПоследнее().
На втором месте с результатом 480 микросекунд на проверку - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом Действует через метод менеджера ПолучитьПоследнее() с двумя записями на скидку.
На третьем месте с результатом 810 микросекунд на проверку - вариант alex-is с непериодическим регистром;
На четвертом месте с результатом 1340 микросекунд - разновидность запроса вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания (без условия ГДЕ, оно проверяется у Выборки);
На пятом месте с результатом 1460 микросекунд - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания с проверкой ГДЕ в запросе.
Базу с обработкой для генерации и прогона тестов и запросами могу скинуть (правда, там ничего не причесано).
На SQL проверю завтра в течение дня.
На всякий случай привожу код проверки в лучшем у меня варианте
- файловая база в быстром терминальном сервере;
- 1000 контрагентов;
- 10 скидок;
- 12 назначений скидок;
- среднее время между назначениями скидок - 60 дней;
- среднее время действия скидки - 30 дней (именно так, хотя не принципиально!);
- интервалы случайные (экспоненциальный закон);
- проверяется скидка на "сегодня" (генерация интервалов идет вглубь),
- 10 прогонов на каждого контрагента+скидку - всего 100000 прогонов.
На первом месте с результатом 460 микросекунд на проверку - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания через метод менеджера ПолучитьПоследнее().
На втором месте с результатом 480 микросекунд на проверку - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом Действует через метод менеджера ПолучитьПоследнее() с двумя записями на скидку.
На третьем месте с результатом 810 микросекунд на проверку - вариант alex-is с непериодическим регистром;
На четвертом месте с результатом 1340 микросекунд - разновидность запроса вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания (без условия ГДЕ, оно проверяется у Выборки);
На пятом месте с результатом 1460 микросекунд - вариант с периодическим регистром сведений с измерениями контрагент и скидка и ресурсом ДатаОкончания с проверкой ГДЕ в запросе.
Базу с обработкой для генерации и прогона тестов и запросами могу скинуть (правда, там ничего не причесано).
На SQL проверю завтра в течение дня.
На всякий случай привожу код проверки в лучшем у меня варианте
Действует = РегистрыСведений.Скидки.ПолучитьПоследнее(Старт, Отбор).ДатаОкончания > Старт;
(79) Могу поставить все, что есть (5$m) на "свой" вариант из (78), если это возможно.
А вообще с большим удовольствием обсудил бы пересечение скидок и суть задачи. Потому, что, если решать задачу "правильно", то Ваш вариант хранения скидок в регистре потребует вложенного запроса. А так из-за азарта сравниваются разные по своим целям подходы.
А вообще с большим удовольствием обсудил бы пересечение скидок и суть задачи. Потому, что, если решать задачу "правильно", то Ваш вариант хранения скидок в регистре потребует вложенного запроса. А так из-за азарта сравниваются разные по своим целям подходы.
(81) Ставка принята. Теперь у нас три участника.
1. Istur с запросом пост (1)
2. alexk-is с запросом пост (3)
3. ildarovich с получением результата через менеджер регистра сведений (78)
(82) Ставка принята. Банк 166 $m
(83) см. (60)
И ещё. Не обязательно делать ставку только в том объеме, что есть в кошельке. Движение $m только началось. Уверен, что любую сумму скопить будет сравнительно просто.
1. Istur с запросом пост (1)
2. alexk-is с запросом пост (3)
3. ildarovich с получением результата через менеджер регистра сведений (78)
(82) Ставка принята. Банк 166 $m
(83) см. (60)
И ещё. Не обязательно делать ставку только в том объеме, что есть в кошельке. Движение $m только началось. Уверен, что любую сумму скопить будет сравнительно просто.
(78) Ставку делать будешь?? Базу в студию. Ну так неинтересно, когда уже какие-то результаты есть( Базу да, выложи.
(79) Я делаю ставку 50, единственное позже отпишусь какой вариант, где ДатаОкончания внутри параметра, или уже потом. Отпишусь сегодня дома.
(80) Вот блин докопался же ты) Ну раз такие обвинения, то вечером буду отвечать по твоим пунктам.
(79) Я делаю ставку 50, единственное позже отпишусь какой вариант, где ДатаОкончания внутри параметра, или уже потом. Отпишусь сегодня дома.
(80) Вот блин докопался же ты) Ну раз такие обвинения, то вечером буду отвечать по твоим пунктам.
(82)(84) Вот тестовая конфигурация 82.
Загрузить в пустую, запустить, открыть обработки/тест, заполнить параметры: число контрагентов, скидок, назначений по каждой паре контрагент-скидка, интервал назначений в днях (средний), срок действия скидки в днях(средний), сохранить параметры.
Затем нажать подготовить, подождать. Заполнятся справочники и регистр. Регистр смотрим через операции.
Потом задаем число циклов (не менее 10 000 для точности), день проверки, вариант (1-3), нажимаем выполнить.
Для единообразия я несколько вольно обошелся со структурой регистра alexk-is. Заранее извиняюсь. На результате это вроде бы не сказывается (ранее приводил результаты, где был отдельный регистр).
Загрузить в пустую, запустить, открыть обработки/тест, заполнить параметры: число контрагентов, скидок, назначений по каждой паре контрагент-скидка, интервал назначений в днях (средний), срок действия скидки в днях(средний), сохранить параметры.
Затем нажать подготовить, подождать. Заполнятся справочники и регистр. Регистр смотрим через операции.
Потом задаем число циклов (не менее 10 000 для точности), день проверки, вариант (1-3), нажимаем выполнить.
Для единообразия я несколько вольно обошелся со структурой регистра alexk-is. Заранее извиняюсь. На результате это вроде бы не сказывается (ранее приводил результаты, где был отдельный регистр).
Прикрепленные файлы:
ТестЧтенияРегистров.cf
(67) Да не волнуйся ты так за $m. Ещё неделя не прошла, а их уже 28. Я так понимаю ещё 3 недели и сотня будет. Нужно только подождать...
Для первых 1500 ТОПа $m пока игра. Ни на что не влияет - безлимитка однако. Уйдешь в минус - Доржи обешал вывести потом в ноль. Так что давай сыграем. Может ещё кто подтянется.
Думаешь 100 $m это много? Чуствуешь ценность или жадничаешь? Вот Ish_2, как мне кажется жмет монету...
Игра есть игра. Играем по честному. Все тестовые материалы выложу в комментарии этой ветки. Результаты здесь же.
(73) Ах да. Istur, сколько ставишь-то.
Для первых 1500 ТОПа $m пока игра. Ни на что не влияет - безлимитка однако. Уйдешь в минус - Доржи обешал вывести потом в ноль. Так что давай сыграем. Может ещё кто подтянется.
Думаешь 100 $m это много? Чуствуешь ценность или жадничаешь? Вот Ish_2, как мне кажется жмет монету...
Игра есть игра. Играем по честному. Все тестовые материалы выложу в комментарии этой ветки. Результаты здесь же.
(73) Ах да. Istur, сколько ставишь-то.
(67)
Задачу понял буквально, она реальная, жизненная, а чем Вы мотивируете последующие уточнения? Не оправданием ли неточностей предложенных Вами вариантов решения? Складывается именно такое мнение.
Задача: необходимо хранить информацию о периодичности действия скидок для контрагентов, и в документе "Реализация товаров и услуг" получать, действует ли скидка в указанный период или нет. Запись в регистр происходит документом "Установка скидок", в котором указывается начало и окончание действия скидки, Скидка - справочник "Скидки" и Контрагент.
Задачу понял буквально, она реальная, жизненная, а чем Вы мотивируете последующие уточнения? Не оправданием ли неточностей предложенных Вами вариантов решения? Складывается именно такое мнение.
(49) А вот быстрое решение "4" для раскритикованных условий неперекрывающихся периодов: Такой код эквивалентен запросу, но пишется короче. Его нельзя использовать в модуле проведения! Там - только запрос:
Если РегистрыСведений.Скидки.ПолучитьПоследнее(Дата, Новый Структура("Контрагент, Скидка", Контрагент, Скидка)).Действует Тогда ... КонецЕслиВЫБРАТЬ Действует ИЗ РегистрСведений.Скидки.СрезПоследних(&Дата, Контрагент = &Контрагент И Скидка = &Скидка) ГДЕ Действует ДЛЯ ИЗМЕНЕНИЯ
(62) Хм. Скромно. Ну, ладно. Пусть будет так.
Итак, начат тотализатор. Делаем ставки. Собран банк 101 $m.
Заявлено 2 участника забега:
1. Istur с запросом пост (1)
2. alexk-is с запросом пост (3)
Принимаются ставки и участники до конца дня по MSK.
Результаты будут объявлены завтра. Надеюсь базу я набить успею :)
Итак, начат тотализатор. Делаем ставки. Собран банк 101 $m.
Заявлено 2 участника забега:
1. Istur с запросом пост (1)
2. alexk-is с запросом пост (3)
Принимаются ставки и участники до конца дня по MSK.
Результаты будут объявлены завтра. Надеюсь базу я набить успею :)
Так. результатов пока нет. Но...
Я ставлю 100 $m, что мой вариант (3) быстрее.
Ish_2, сколько ставишь и на кого? Хватит юлить. Конкретно давай.
Будет банк, будет и игра.
Кто кому сколько должен посчитаем по результатам тестирования. Расплатимся после реализации соответствующего функционала. Доржи обещал сделать возвожность передачи $m. В крайнем случае можно скачать, сколько там причитается файлов и $m будут перечислены.
Делай уже ставку. Не томи.
Я ставлю 100 $m, что мой вариант (3) быстрее.
Ish_2, сколько ставишь и на кого? Хватит юлить. Конкретно давай.
Будет банк, будет и игра.
Кто кому сколько должен посчитаем по результатам тестирования. Расплатимся после реализации соответствующего функционала. Доржи обещал сделать возвожность передачи $m. В крайнем случае можно скачать, сколько там причитается файлов и $m будут перечислены.
Делай уже ставку. Не томи.
Значит так.
:) :) :)
В регистре накопления мы получаем 2 записи: начало и окончание. Если срок действия скидки 1 год, то мы получаем ещё не маленькую толпу записей итогов. Это избыточная информация.
Так делать нельзя... :)
Можно сделать так.
1. Регистр сведений.
Измерения: Скидка, Контрагент, ДатаНачала (тип Дата).
Ресурсы: ДатаОкончания (тип Дата)
Реквизиты: нет.
:) :) :)
В регистре накопления мы получаем 2 записи: начало и окончание. Если срок действия скидки 1 год, то мы получаем ещё не маленькую толпу записей итогов. Это избыточная информация.
Так делать нельзя... :)
Можно сделать так.
1. Регистр сведений.
Измерения: Скидка, Контрагент, ДатаНачала (тип Дата).
Ресурсы: ДатаОкончания (тип Дата)
Реквизиты: нет.
Запрос.Текст = "ВЫБРАТЬ ПЕРВЫЕ 1
| 1
|ИЗ
| РегистрСведений.ПериодДействияСкидок КАК ПериодДействияСкидок
|ГДЕ
| Контрагент = &Контрагент
| И Скидка = &Скидка
| И ДатаОкончания >= &Дата
| И ДатаНачала <= &Дата";
Запрос.УстановитьПараметр("Дата", НачалоДня(Дата));
Если Не Запрос.Выполнить().Пустой() Тогда Показать
проверка условий при использовании виртуального регистра предпочтительнее делать в параметрах этого регистра . а не через ГДЕ..и это говорили много где. и это правильно по многим критериям. ОБРАЩЕНИЕ к "виртуальному" регистру (если таковой имеется и его применение оправдано) рекомендуемо использовать. .существует как минимум 2 схожих решения одной задачи. и не на столько уж сильно они разняться. про то что стремление поддерживать "стандарты" 1С это ПЛЮС я считаю..так как потом если ктото будет разбираться в написании кода ему будет проще всё понять.но это не всегда выходит.
(25)
Из рассказа «Учитель словесности» (1894) Антона Павловича Чехова (1860—1904). Его герой — учитель истории и географии Ипполит Ипполитыч — «или молчал, или же говорил только о том, что всем давно уже известно». Так, он вполне серьезно сообщал, что «лето не то что зима», что «без пищи человек не может существовать» и т. д. И даже умирая, будучи в бреду, он говорил только очевидные вещи: «Волга впадает в Каспийское море... Лошади кушают овес и сено...»
Обычно цитируется иронически, когда хотят указать и а то, что собеседник изрекает очевидные, прописные, банальные, общеизвестные истины
Из рассказа «Учитель словесности» (1894) Антона Павловича Чехова (1860—1904). Его герой — учитель истории и географии Ипполит Ипполитыч — «или молчал, или же говорил только о том, что всем давно уже известно». Так, он вполне серьезно сообщал, что «лето не то что зима», что «без пищи человек не может существовать» и т. д. И даже умирая, будучи в бреду, он говорил только очевидные вещи: «Волга впадает в Каспийское море... Лошади кушают овес и сено...»
Обычно цитируется иронически, когда хотят указать и а то, что собеседник изрекает очевидные, прописные, банальные, общеизвестные истины
(29) Потому что существуют 3 варианта решения, и доказательства какое из них лучшее нет. Есть только люди отстаивающие разные решения.
(30) Принимается. Я проведу замеры. Обработки есть, помогающие в этом, вроде я что-то такое видел, по тестированию быстроты выполнения отчета, но вот не помню что и где(
(31) Да, если записей 0 или 1, то выгоднее отбор по реквизитам делать после, но вот если их много, то согласен, внутри. Но в моем случае их 0-1. Хотя это тоже надо тестировать.
(30) Принимается. Я проведу замеры. Обработки есть, помогающие в этом, вроде я что-то такое видел, по тестированию быстроты выполнения отчета, но вот не помню что и где(
(31) Да, если записей 0 или 1, то выгоднее отбор по реквизитам делать после, но вот если их много, то согласен, внутри. Но в моем случае их 0-1. Хотя это тоже надо тестировать.
(32) Нет смысла сравнивать регистры с 1-2 записями.
Допустим ты выиграл 0.05 сек. Что это даёт ? Зачем такой выигрыш ?
С точки зрения пользователя сравнивать нужно на 10 000 записях.
И тогда по результатам теста можно будет сказать , что тот или иной подход в среднем более оптимален.
Допустим ты выиграл 0.05 сек. Что это даёт ? Зачем такой выигрыш ?
С точки зрения пользователя сравнивать нужно на 10 000 записях.
И тогда по результатам теста можно будет сказать , что тот или иной подход в среднем более оптимален.
Istur пишет:
Нуну. Реквизиты присутствуют в виртуальных таблицах. Я даже специально отрыл параметры виртуальной таблицы, вдруг ошибаюсь. Но нет, ошибаетесь вы. ДатаОкончания - реквизит, доступный там. И смотрите регистр "Скидки наценки номенклатуры", то что такой вариант использует 1с, уже говорит о многом.
Нуну. Реквизиты присутствуют в виртуальных таблицах. Я даже специально отрыл параметры виртуальной таблицы, вдруг ошибаюсь. Но нет, ошибаетесь вы. ДатаОкончания - реквизит, доступный там. И смотрите регистр "Скидки наценки номенклатуры", то что такой вариант использует 1с, уже говорит о многом.
ну, вообще, это не так :)
что есть виртуальная таблица регистра (РН, РБ) - это не более чем та же оригинальная таблица, которая просто сгруппирована по измерениям и сложена, соответственно, по ресурсам. И всё. Вы можете её сами эмулировать запросом. (Единственное, 1С сама вычисляет по каким полям и как группировать по в ВЫБРАТЬ - но это уже другая тема). Поэтому в таких виртуальных таблицах не может быть реквизитов физически - они просто не будут группироваться и у вас будут кривые остатки и обороты. Поэтому, чтобы поиметь нужные данные в виртуалке, обычно реквизит переносят в измерение.
А вот для регистров сведения тут чуть проще - поскольку СрезПоследних и Первых выдает только одну реальную строку регистра, то там, да, 1С-ка выводит реквизиты, почему бы и нет, здесь нет никаких припятствий.
P.S. вот тут про это классно расписано в картинках
(46) Да безусловно, вы правы и прошу прощения за допущенную мною неточность, реквизиты доступны в параметрах виртуальной таблицы регистра сведений, но не доступны в регистрах накопления. Просто в данном случае идет обсуждение регистров сведений, вот я и допустил такую оплошность в формулировках.
(86) Да времени вот как раз и нет, так что уже немного жалею, что создал эту тему) Хотя нет, знание как делать лучше оно важнее, на это время потратить можно.
(87) Выздоравливай!
(80) Теперь по твоим условиям, когда скидка может отменяться раньше назначенного срока. Да, изменять старый документ не стоит. В этом случае я велосипед изобретать не буду, а просто опишу как сделала 1с, я согласен с их решением. Создается новый документ "Отмена скидок". В типовом механизме в табличной части указываются отменяемые документы "Установка скидок". Движения по регистру - дата отмены пишется в период. И то есть в запросе СредПоследних окажется именно эта строчка, записанная отменой скидок. Но тогда для универсальности нужно добавить некоторый ресурс типа булево "Действует". И считывать по нему действует скидка или нет. Потому что в моем случае можно было проверят просто вернет запрос хоть одну запись или нет, а здесь же уже в регистре содержатся записи с отменой.
Всем - предлагаю устроить 2 тотализатора, первый по моим начальным условиям, просто на проверку быстроты выполнения запроса. Второй - на задачу скидок, раз Сергею она так нравится. Мне она тоже интересна в принципе. Ее условия тогда сделаем еще более универсальными. - Скидка устанавливается на некоторый период, но может устанавливаться и на неограниченный период. Так же скидка может отменяться раньше окончания срока. И в запросе мы должны получить не просто действует скидка или нет, а процент скидки, ведь в документах нужно именно это, процент скидки. Тут тоже наверное победителей будем определять по скорости выполнения итогового запроса.
Лично я полностью поддерживаю и защищаю типовой механизм 1с. Сергей кажется за версию с 2 записями в РС, но за себя он скажет сам) Может еще кто что предложит. И предлагаю ставки унифицировать до одного значения, А то кто-то 1 ставит, а другой 100.
(87) Выздоравливай!
(80) Теперь по твоим условиям, когда скидка может отменяться раньше назначенного срока. Да, изменять старый документ не стоит. В этом случае я велосипед изобретать не буду, а просто опишу как сделала 1с, я согласен с их решением. Создается новый документ "Отмена скидок". В типовом механизме в табличной части указываются отменяемые документы "Установка скидок". Движения по регистру - дата отмены пишется в период. И то есть в запросе СредПоследних окажется именно эта строчка, записанная отменой скидок. Но тогда для универсальности нужно добавить некоторый ресурс типа булево "Действует". И считывать по нему действует скидка или нет. Потому что в моем случае можно было проверят просто вернет запрос хоть одну запись или нет, а здесь же уже в регистре содержатся записи с отменой.
Всем - предлагаю устроить 2 тотализатора, первый по моим начальным условиям, просто на проверку быстроты выполнения запроса. Второй - на задачу скидок, раз Сергею она так нравится. Мне она тоже интересна в принципе. Ее условия тогда сделаем еще более универсальными. - Скидка устанавливается на некоторый период, но может устанавливаться и на неограниченный период. Так же скидка может отменяться раньше окончания срока. И в запросе мы должны получить не просто действует скидка или нет, а процент скидки, ведь в документах нужно именно это, процент скидки. Тут тоже наверное победителей будем определять по скорости выполнения итогового запроса.
Лично я полностью поддерживаю и защищаю типовой механизм 1с. Сергей кажется за версию с 2 записями в РС, но за себя он скажет сам) Может еще кто что предложит. И предлагаю ставки унифицировать до одного значения, А то кто-то 1 ставит, а другой 100.
Ребята, беру таймаут. Температура 39. Всё будет, но чуть позже.
Приношу свои извинения за то, что не смогу опубликовать результаты сейчас. Нужно немного отлежаться.
Чтож возможно это шанс для других людей за это время стать участником или сделать ставочку.
Приношу свои извинения за то, что не смогу опубликовать результаты сейчас. Нужно немного отлежаться.
Чтож возможно это шанс для других людей за это время стать участником или сделать ставочку.
Итак, на SQL получились следующие результаты:
Замер. Контрагентов: 10 Скидки: 10
Istur
Завершено за 0,622 сек.
alexk-is
Завершено за 0,254 сек.
ildarovich
Завершено за 0,091 сек.
Замер. 100 повторов с выбранным отбором
Istur
Завершено за 0,674 сек.
alexk-is
Завершено за 0,261 сек.
ildarovich
Завершено за 0,102 сек.
Приблизительно такие же результаты получаются при обработке большого количества контрагентов.
Как видно из результатов, победителем становится ildarovich
Победитель принимает поздравления и забирает банк в 166 $m
Замер. Контрагентов: 10 Скидки: 10
Istur
Завершено за 0,622 сек.
alexk-is
Завершено за 0,254 сек.
ildarovich
Завершено за 0,091 сек.
Замер. 100 повторов с выбранным отбором
Istur
Завершено за 0,674 сек.
alexk-is
Завершено за 0,261 сек.
ildarovich
Завершено за 0,102 сек.
Приблизительно такие же результаты получаются при обработке большого количества контрагентов.
Как видно из результатов, победителем становится ildarovich
Победитель принимает поздравления и забирает банк в 166 $m
Теперь о том, как проводилось тестирование.
Платформа 1С:Предприятие 8.2.14.533 + MS SQL 2005 Standart + Windows Server 2008 Standart
База УПП 1.2.39.1 (Режим совместимости: Не использовать) объем базы 18Gb
Тестирование проводилось на добавленных объектах с помощью обработок. Конфигурация и обработки прилагаются.
Платформа 1С:Предприятие 8.2.14.533 + MS SQL 2005 Standart + Windows Server 2008 Standart
База УПП 1.2.39.1 (Режим совместимости: Не использовать) объем базы 18Gb
Тестирование проводилось на добавленных объектах с помощью обработок. Конфигурация и обработки прилагаются.
Прикрепленные файлы:
1Cv8.cf
01 Заполнение справочников.epf
02 Заполнение регистров.epf
03 Проверка запросов 1.epf
03 Проверка запросов 2.epf
(93) Не совсем так. В описании задачи был вопрос: "Какую структуру регистра применить для наиболее эффективного определения действия определенной скидки у определенного контрагента." Собственно ответом служат структура регистра и способ получения результата. Вот если бы было бы наложено ещё ограничение на способ получения результата, или нужно было бы получить все распространяющиеся на контрагента скидки, то тогда можно было бы пободаться. А единичный срез даже в SQL средствами встроенного языка получается быстрее, чем запросом.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот