Вход | Регистрация

  1  2  3  4   
Работа :: Вакансии

Старший Разработчик 1С

Старший Разработчик 1С
Я
   Anna-recruiter
 
11.04.18 - 11:53
Вы хотите работать с современными Agile подходами к разработке, используя их и учась им? Ставите целью саморазвитие и стремитесь реализовывать свой потенциал? Желаете быть частью динамичного e-commerce бизнеса, жить внутри развитой корпоративной среды, предоставляющей возможность профессионального и личностного развития? Тогда эта вакансия для Вас!

Преимущества работы у нас:
1.    Внутренний заказчик - основную часть бизнес-инициатив мы получаем от сотрудников бизнес-подразделения нашей компании. Внутренняя коммуникация для уточнения требований и деталей реализации позволяет нам разрабатывать более точный и востребованный бизнес-продукт.
2.    Современные методологии - такие как Agile, Scrum, Kanban и DevOps позволяют нам успешно реагировать на изменяющиеся требования бизнеса и современного рынка e-commerce.
3.    Большая честная компания - социальная защита сотрудников нашей компании является залогом стабильной работы. Оформление по ТК РФ. Белая зарплата выплачивается по графику, без задержек и в полном объеме. Годовой бонус по достижению целей компании. Добровольное медицинское страхование (ДМС), страхование жизни, страхование от несчастного случая (после испытательного срока). Налоговые вычеты по НДФЛ, справки для ипотеки.
4.    Развитие и обучение - повышаем квалификацию специалистов, проводим внутренние и внешние обучения. Компенсируем корпоративное обучение английскому и немецкому языкам.

О нас:
Мы, компания eSolutions, входим в немецкий холдинг Otto Group - мировой лидер дистанционной торговли и электронной коммерции, компания с 60-летней историей, офисы которой расположены в 20 странах мира, а общая численность сотрудников превышает 53 000 человек.

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

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

Задачи, которые Вам предстоит решать:
1.    Разрабатывать внутренние веб-сервисы в учетной системе 1С для получения данных из внешних источников.
2.    Интегрироваться с внешними веб-сервисами для отправки данных из учетной системы 1С.
3.    Разрабатывать реализацию бизнес-логики в учетной системе 1С.
4.    Разрабатывать сводные аналитические отчеты в учетной системе 1С с разным количеством источников данных.
5.    Повышать общую отказоустойчивость учетной системы 1С через оптимизацию запросов и процессов, рефакторинг.
6.    Изучать и использовать новые эффективные подходы в разработке, использовать встроенные инструменты и реализовывать интеграции с внешними инструментами, повышающими качество, скорость разработки, тестирования и внедрения, а также качество поддержки.

Качества, которыми Вы обладаете:
1.    Вы хотите работать на крупном проекте, в команде с разделенным функционалом, состоящих из менеджера проекта, разработчика 1С, разработчика web, аналитика, тестировщика, с применением современных методов разработки и ведения проектов.
2.    Вам нравится решать сложные задачи в срок.
3.    Вы активно предлагаете решения задач на обсуждениях.
4.    Вы стремитесь создать стабильно работающий продукт.
5.    Вам нравится изучать новые методологии, подходы, системы, фреймворки, языки программирования.
6.    Вы мыслите категориями, где 1С может быть одной из группы систем.

Мы ценим наших сотрудников, поэтому дополнительно предоставляем следующие льготы:
Полная оплата по больничному листу до 30 дней в году.
Корпоративное обучение английскому/немецкому языку.
Частичная компенсация расходов на питание.
Скидка 15% на бренды группы – OTTO, Quelle, WITT и bonprix и в в интернет-магазинах наших клиентов.
Гибкий график работы (начало рабочего дня с 7 до 10 утра), 9 часовой рабочий день, обеденный перерывы 45 минут, рабочий день в пятницу сокращен на 1 час. Место работы – ст.м. Савёловская, Бизнес Центр «Фактория».

Резюме можно присылать на Anna.Krasner@ottoruss.ru
 
 
   Мандалай
 
201 - 11.04.18 - 17:16
(199)Я как то читал рекомендацию, в которой указывалось что метод ТипЗначения при использовании его в запросе выполняет дополнительно преобразование к тому типу, который был указан в параметрах. Соответственно метод Ссылка отрабатывает быстрее, поскольку он не выполняет никаких преобразований. Но это было довольно давно, возможно с тех пор был изменен механизм преобразования текста запроса 1С в SQL.
   RomanYS
 
202 - 11.04.18 - 17:17
(197) ты привел статью с ИТС времен 8.0-8.1, тогда типов не было в запросе. В (194) тебе привели эквивалентные решения без ссылки (мне кстати явное соединение с двумя таблицами больше нравится).

(200) параметры можно не передавать есть Тип()

По производительности ответ в (195)
   Avalone2010
 
203 - 11.04.18 - 17:19
Единственное что тип значения позволяет тип получить, а ссылка сравнить на тип. т.е.
ВЫБРАТЬ ТИПЗНАЧЕНИЯ(Продажи.Регистратор)
ИЗ РегистрНакопления.Продажи КАК Продажи

с ссылкой будет сделать намного труднее.
   Мыш
 
204 - 11.04.18 - 17:19
(195) Было интересно, кто же не поленится сделать пример )

(200) "ТипЗначения" появился в запросах вместе с "Тип" позже "Ссылка". Емнип, в документации к релизу было написано, что это для удобства и проч. Искать пруфы не буду, я не Билли )
   Avalone2010
 
205 - 11.04.18 - 17:20
(204) да аж самому интересно стало что выпросил доступ у админов на скуль :)
   DTX 4th
 
206 - 11.04.18 - 17:32
Хоть что-то интересное в этой ветке)

В общем, имеет смысл использовать ССЫЛКА, если нет необходимости использовать ТипЗначения, т.к читабельнее.

Не понимаю, почему некоторые вместо ВЫРАЗИТЬ пользуется соединениями. Потом же на запрос без слёз не взглянешь.
   vvp91
 
207 - 11.04.18 - 17:32
(195) Однако! Хотя я любитель ТИПЗНАЧЕНИЯ, но наука требует жертв.
Я сделал замеры производительности, вот запросы к ERP 2.2 на PostgreSQL-1C 9.4:

И действительно, проверка, что регистратор есть ССЫЛКА или ССЫЛКА чуть быстрее.
При этом проверка, что регистратор НЕ (ССЫЛКА ИЛИ ССЫЛКА) одинаково с НЕ В (ТИП, ТИП)

// ТипЗначения1 - проверка, что тип регистратора в списке - ВРЕМЯ 0.23

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Записей
ИЗ
    РегистрНакопления.СебестоимостьТоваров КАК ТТ
ГДЕ
    ТИПЗНАЧЕНИЯ(ТТ.Регистратор) В (
        ТИП(Документ.ПоступлениеТоваровУслуг)
        ,ТИП(Документ.РеализацияТоваровУслуг))

// ТипЗначения2 - проверка, что тип регистратора НЕ в списке - ВРЕМЯ 0.25

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Записей
ИЗ
    РегистрНакопления.СебестоимостьТоваров КАК ТТ
ГДЕ
    НЕ ТИПЗНАЧЕНИЯ(ТТ.Регистратор) В (
        ТИП(Документ.ПоступлениеТоваровУслуг)
        ,ТИП(Документ.РеализацияТоваровУслуг))

// ТипЗначения3 - проверка, что тип регистратора в списке через параметр запроса - ВРЕМЯ 0.23

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Записей
ИЗ
    РегистрНакопления.СебестоимостьТоваров КАК ТТ
ГДЕ
    ТИПЗНАЧЕНИЯ(ТТ.Регистратор) В (&Типы)

// ССЫЛКА1 - проверка, что тип регистратора в списке - ВРЕМЯ 0.17

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Записей
ИЗ
    РегистрНакопления.СебестоимостьТоваров КАК ТТ
ГДЕ
    ТТ.Регистратор ССЫЛКА Документ.ПоступлениеТоваровУслуг
    ИЛИ ТТ.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг

// ССЫЛКА2 - проверка, что тип регистратора НЕ в списке - ВРЕМЯ 0.25

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Записей
ИЗ
    РегистрНакопления.СебестоимостьТоваров КАК ТТ
ГДЕ
    НЕ (ТТ.Регистратор ССЫЛКА Документ.ПоступлениеТоваровУслуг
        ИЛИ ТТ.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг)

   Вафель
 
208 - 11.04.18 - 17:33
.02 сек - это погрешность
   Новиков
 
209 - 11.04.18 - 17:34
Мандалай, ты прав в том ключе, что когда-то давно действительно были такие рекомендации: юзать Ссылку в ГДЕ. Сейчас, судя по всему, все это кануло в небытие. Но есть такие ситуации, когда ты Ссылкой не сможешь выкрутиться - какие, да? Очень простые - когда у тебя в запрос передается таблица как параметр, в ней есть реквизит не составного типа, а в тебя в запросе проверка по Ссылке. Тогда во времени исполнения ты получишь трабл "Несовместимые типы", и в этом случае костыль в виде ТипЗначения = Тип тебя спасет.
   vvp91
 
210 - 11.04.18 - 17:35
(208) К сожалению нет, 0.06 сек это не погрешность.
Все замеры делались многократно, на прогретой базе.
 
 Рекламное место пустует
   Avalone2010
 
211 - 11.04.18 - 17:36
(210) Даешь трассировки и планы запросов!
   Вафель
 
212 - 11.04.18 - 17:36
(210) именно что погрешность
   Вафель
 
213 - 11.04.18 - 17:37
(210) Каков вообще разброс времени выполнения одного и того же запроса?
   Мыш
 
214 - 11.04.18 - 17:37
(210) Пока не зачехлил, скинь планы запросов, да )
   vvp91
 
215 - 11.04.18 - 17:37
(213) Доверительный интервал - 0.02 сек.
   Avalone2010
 
216 - 11.04.18 - 17:40
(210) погрешность в 0.06 от 0.25 это  порядка 25% времени - нехилая такая погрешность
   vvp91
 
217 - 11.04.18 - 17:42
(211) (214) За планами надо лезть глубже.
Уже не хочу.

У меня была реакция на насмешку в (119) "Еще анекдот - прогер, который первым со мной беседовал, для проверки на тип значения в запросе предложил использовать ТипЗначения."
Я выразил свою позицию, что я согласен с программистом, который собеседовал Мандалая, и обосновал позицию.

(216) Я наоборот утверждаю, что 0.06 погрешностью не является.
Так что твое высказывание не ко мне, а к (212)
   Мандалай
 
218 - 11.04.18 - 17:44
(209)Спасибо, я совершенно согласен, я же не говорю что метод ТипЗначения чмо и отстой, но каждому методу свое место.
   Мандалай
 
219 - 11.04.18 - 17:44
(217)Анекдотом в данной ситуации является то, что собеседовать посадили человека некомпетентного.
   Cyberhawk
 
220 - 11.04.18 - 17:45
(219) Че-то много букв понаписали, в чем там соль?
   Мыш
 
221 - 11.04.18 - 17:46
(219) Невозможно знать всё на свете. Незаслуженно назвали некомпетентным собеседователя.
   Смотрящий
 
222 - 11.04.18 - 17:47
И чо, реально кто-то отсюда постучался на вакуху ?
   Вафель
 
223 - 11.04.18 - 17:47
Хотя бы показать что запросы разные
тут получается разница:
А = 1 ИЛИ А=2
против
А в (1, 2)
   Мандалай
 
224 - 11.04.18 - 17:47
(222)Судя по постам кто-то скинул.
   Вафель
 
225 - 11.04.18 - 17:48
на ms может и другая картина быть
   Мандалай
 
226 - 11.04.18 - 17:49
(221)Если товарищ принимает решение о принятии кого-то на работу, он априори должен знать больше того кого собеседует, иначе как он примет решение?
   Avalone2010
 
227 - 11.04.18 - 17:50
(223) тут разница большая. или индексы не будет использовать(в теории) а в будет(в теории)
   vvp91
 
228 - 11.04.18 - 17:53
(227) Индексы для ИЛИ по одному полю будут всегда использоваться.
А вот индексы по ИЛИ по разным полям использоваться не будут.
Об этом есть конкретная статья "Эффективные условия запросов" в стандартах разработки - https://its.1c.ru/db/v8std#content:2149184307:hdoc
   mr_K
 
229 - 11.04.18 - 17:53
(226) Ошибочное утверждение.
   strrike
 
230 - 11.04.18 - 17:56
(229) обоснуй.
   Avalone2010
 
231 - 11.04.18 - 17:58
(228) странно у меня другая информация
Использование логического ИЛИ в секции ГДЕ запроса
Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

Например, запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

следует заменить на запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"

https://its.1c.ru/db/metod8dev#content:5842:hdoc:or
   vvp91
 
232 - 11.04.18 - 18:02
(231) Мои 146% свежее - посмотри даты на статьях.
"Твоя" статья - 07.12.2015
"Моя" - "Раздел обновлен", т.е. прямо совсем свежак.
   Avalone2010
 
233 - 11.04.18 - 18:03
(231)доступа туда нет :(
 
 
   youalex
 
234 - 11.04.18 - 18:03
(231) Тогда можно писать  ГДЕ Артикул В("001" ,  "002" )
)
   vvp91
 
235 - 11.04.18 - 18:08
(231) Я делал в свое время замеры производительности по этой теме.
Если Артикул проиндексирован, то индекс для ИЛИ будет использован на всех поддерживаемых видах СУБД.

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

Смысл - застращать от использования ИЛИ. Лучше "запретить" во всех случаях, чем объяснять где можно, а где нельзя.
   Мандалай
 
236 - 11.04.18 - 18:09
(234)А 1С верный план запроса построит при таком тексте запроса?
   shuhard
 
237 - 11.04.18 - 18:09
(222) чисто конкретно пол форума уже в очереди на собеседование
   Мандалай
 
238 - 11.04.18 - 18:10
(235)А может просто оптимизировали работу 1С с SQL
   Новиков
 
239 - 11.04.18 - 18:12
(218) Это кстати не все траблы Ссылки. Я привел вычурный случай, - это типа универсального какого-то алгоритма, когда ты не можешь предсказать, какого типа будет это поле в ГДЕ. Соотв., из этого же следует, что отбор по типу значения в той же схеме компоновки, возможен, когда ты отдельно сделаешь поле ТипЗначения(Реквизит), и тогда ты штатно сможешь по нему отобраться. Но это все работает, когда набор данных схемы компоновки - запрос. Как только, ты его изменишь на объект, сразу получаешь болтом, потому что ты уже не сможешь определить тип передаваемого значения, и как следствие, ты не сможешь сделать отбор по типу. Т.е. понимаешь, вот этот совет, использование ссылки в где, надо дополнять так "Где это физически возможно". Я тебе два случая привел, где это физически невозможно, и поэтому если говорить обобщенно - юзать надо контекстно эти два механизма.
   youalex
 
240 - 11.04.18 - 18:12
(236) 1С(файловая версия) не знаю, а вот скуль - хайли-лайкли.  Было бы странно, если бы было иначе.
А вот ИЛИ на разные поля - действительно лучше разносить через ОБЪЕДИНИТЬ (было пару инцидентов)
   vvp91
 
241 - 11.04.18 - 18:13
(233) В свежей статья на ИТС написано следующее:

2. Оператор ИЛИ
2.1. В основном условии оператор ИЛИ можно использовать только для последнего из используемых или единственного поля индекса, когда оператор ИЛИ можно заменить на оператор В.

ПРАВИЛЬНО:
ГДЕ
    Таблица.Поле = &Значение1
    ИЛИ Таблица.Поле = &Значение2

т.к. можно переписать при помощи оператора В (специально переписывать не нужно, можно оставить, как есть):
ГДЕ
    Таблица.Поле В (&Значения)

НЕПРАВИЛЬНО:
ГДЕ
    Таблица.Поле1 = &Значение1
    ИЛИ Таблица.Поле2 = &Значение2

нельзя переписать при помощи "В", но можно переписать при помощи "ОБЪЕДИНИТЬ ВСЕ" (каждое поле Поле1 и Поле2 должны быть проиндексированы):
ГДЕ
    Таблица.Поле1 = &Значение1

ОБЪЕДИНИТЬ ВСЕ

ГДЕ
    Таблица.Поле2 = &Значение1

Примечание: заменить ИЛИ на ОБЪЕДИНИТЬ ВСЕ можно не всегда, убедитесь, что результат будет действительно тем же, что и при ИЛИ, перед тем, как применять.

2.2. В дополнительном условии оператор ИЛИ можно использовать без ограничений.

ПРАВИЛЬНО 1:
ГДЕ
    Таблица.Поле1 = &Значение1// Основное условие (использует индекс)

    И// Дополнительное условие (можно использовать ИЛИ)

    (Таблица.Поле2 = &Значение2 ИЛИ Таблица.Поле3 = &Значение3)

ПРАВИЛЬНО 2:
ГДЕ
    (Таблица.Поле1 = &Значение1 ИЛИ Таблица.Поле1 = &Значение2)
    И
    (Таблица.Поле2 = &Значение3 ИЛИ Таблица.Поле2 = &Значение4)

т.к. можно переписать при помощи В (специально переписывать не нужно, можно оставить, как есть):
ГДЕ
    Таблица.Поле1 В (&Значения1)  // Основное условие

    И Таблица.Поле2 В (&Значения2)// Дополнительное условие (или наоборот)

   Новиков
 
242 - 11.04.18 - 18:14
Кстати, по той же СКД, давно просят по составному типу сделать дефаултное добавление тип значения реквизита, чтобы можно было пользователю в настройках компоновке отбираться не задумываясь о том, есть ли поле с типом в полях компоновки. В 8.3.11 такого еще нет. В .12 - хз. Мож кто в курсе уже? :)
   Мандалай
 
243 - 11.04.18 - 18:16
(239)"Как только, ты его изменишь на объект, сразу получаешь болтом, потому что ты уже не сможешь определить тип передаваемого значения, и как следствие, ты не сможешь сделать отбор по типу."
Почему не смогу? Если ТЗ, которая является объектом сразу при создании типизировать, то можно и на тип проверить.
   Новиков
 
244 - 11.04.18 - 18:19
(243) Тебе нужно добавить тип значения поля отдельным полем в объект. Сечешь фишку? Трабл.
   Мандалай
 
245 - 11.04.18 - 18:21
(244)Зачем? Проверить сейчас не на чем, но по моему когда создаешь ТЗ, и ее колонки, каждой колонке через ОписаниеТипов задаешь свой тип, и в запросе спокойно работаешь с типами.
   Мандалай
 
246 - 11.04.18 - 18:29
Кстати да, (207) а вот это двойное фаталити.
   Avalone2010
 
247 - 11.04.18 - 18:35
Так как на собеседовании то отвечать?А то вдруг я пойду и меня спросят?
   Avalone2010
 
248 - 11.04.18 - 18:37
(241)в пункте 2.2 не seek where ли будет?
   Мандалай
 
249 - 11.04.18 - 18:39
(247)На мисту отправляй, пусть тут спрашивают, если чего-то не знают.
 
 Рекламное место пустует
   Новиков
 
250 - 11.04.18 - 19:19
(245) =) Чувак, ты не можешь "спокойно работать с типами", т.к. для того, чтобы сделать отбор по типу в настройке компоновке или в схеме компоновке у тебя должно быть это поле для отбора. У тебя его не будет. И поэтому ты можешь обтипизировать колонки объекта сообразно твоему понятию о хорошем и плохом, но отдельного поля тип у тебя не будет. И, соответственно, ты не сможешь сделать отбор. Так понятнее?
   Cyberhawk
 
251 - 11.04.18 - 20:05
(250) Вычисляемое поле в СКД не предлагать?
   Волшебник
 
252 - 11.04.18 - 20:26
(40) Рекламодатель всегда прав.
   Новиков
 
253 - 12.04.18 - 11:00
(251) есть две вещи, которые тебе надо знать про вычисляемые поля:
1. они появляются в отборах, когда ты укажешь для них тип. Мы говорим про случай, когда тип - неизвестен, соответственно отбор по такому полю ты не сделаешь.
2. пользовательские поля (выражение) в настройках компоновки при наборе данных объект, когда ты получаешь его по ТипЗначения(ТвоеПоле) аналогично не доступны в отборе.

Выше, предлагалось добавить в набор отдельное поле ТипПоля и при формировании набора делать ТипЗнч(НоваяСтрока.ТвоеПоле); - мы сейчас забьем даже на то, что вроде как по условию задачи этого делать нельзя (у нас уже есть готовый набор, есть готовый отчет и мы просто хотим отобраться). Мы видим, да наше отборочное поле появилось в отборах и вроде победа. Но как отобраться по ТИПУ? Если бы набор данных был запрос, вопросов нет - платформа предложит тебе тип в параметра отбора. Если набор данных - объект, она тебе этого не предложит, и как ты отберешься в этом случае? :) Это общая проблема, которая по крайне мере в 8.3.11 не решена в той формулировке, в которой она поставлена.
   Cyberhawk
 
254 - 12.04.18 - 11:09
(253) Как это тип не известен? Тип будет "Тип"
   Новиков
 
255 - 12.04.18 - 11:11
(254) отберись по нему.
   GANR
 
256 - 12.04.18 - 11:13
(0) Это еще что за сетевой маркетинг?
   Avalone2010
 
257 - 12.04.18 - 11:24
(253)(250) Может я не совсем понял в чем суть дискусии но запрос типа
ВЫБРАТЬ ПЕРВЫЕ 1
    ЗаказыПокупателей.Период,
    ЗаказыПокупателей.Регистратор,
    ТИПЗНАЧЕНИЯ(ЗаказыПокупателей.Регистратор) КАК ТипРегистратора
ИЗ
    РегистрНакопления.ЗаказыПокупателей КАК ЗаказыПокупателей
засунутый в СКД позволяет в пользовательском режиме делать отбор по полю ТипРегистратора. И не надо пользовательских полей.
   Новиков
 
258 - 12.04.18 - 11:28
(257) Конечно не понял. У тебя набор данных - запрос. Измени на объект, подсунь туда его и предложи - как отобраться по типу.
   Cyberhawk
 
259 - 12.04.18 - 11:32
(255) Да, с вычисляемым полем СКД борода.
С полем, выбранным в запросе, проблем нет - в отборе можно выбирать тип, как и пишет товарищ (257).
С набором данных "Объект" тоже, выходит, борода.
Однако, даже если тип значения в самом запросе выбирается, то и там не все гладко :) Если вид сравнения отбора СКД сделать "В списке" или "Не в списке" и засунуть в список значений тип, который в результате запроса не фигурирует, то результирующий запрос СКД ругается "Неверные параметры в операции сравнения. Нельзя сравнивать поля неограниченной длины и поля несовместимых типов". Такие дела, надо будет запомнить )
   Новиков
 
260 - 12.04.18 - 11:39
(259) >>С полем, выбранным в запросе, проблем нет
Чувак, все таки - на самом деле, есть проблема то. Тебе нужно это поле протащить в поля набора :) Т.е. сделать, как выше чел пишет ТИПЗНАЧЕНИЯ(ЗаказыПокупателей.Регистратор) КАК ТипРегистратора. Пользователю такая вундер-вафля не нужна, он хочет просто в отборе раскрыть плюс, вытащить поле и сделать уже свой отбор. Чтоб такое было, нужно чтобы платформы автоматом добавляла в поля набора (явно или нет) для каждого поля его фантом ТИПЗНАЧЕНИЯ(ЭтоПоле), тогда эта проблема уходит. Пока, в 8.3.12 я не смотрел, такой фичи нет, и приходится везде где есть схема компоновки, а это не только сама отчет - это учитывать. Но сам этот эпичный диспут начался с того, что выше чел вел политику про отбор по ГДЕ через ССЫЛКА. Вот этот диспут наглядно показывает, что такое не катит в общем случае в компоновке вообще никак.
   Cyberhawk
 
261 - 12.04.18 - 11:46
(260) Не понял, в чем проблема
   Новиков
 
262 - 12.04.18 - 12:06
(261) сделай простейшую схему компоновки с набором - запрос. В полях сделай ОДНО поле (Реквизит1), в котором укажи реквизит составного типа, при этом тип не указывай в настройках.

Задача: сделать на уровне пользователя отбор по этому полю.
Решение: в пользовательском поле, сделать поле, в котором указать в качестве выражения ТипЗначения(Реквизит1). Иду в отбор и? БОЛТ. Там нет этого поля. Таки как отобраться бедолаги?
   Cyberhawk
 
263 - 12.04.18 - 12:16
(262) А, Я-то в (259) веду речь об отдельном поле, содержащем тип значения. А ты проблемой называешь то, что в изходный запрос нельзя добавлять новые поля, так?
   Гаврилин Игор
 
264 - 12.04.18 - 12:24
Друзья! я просмотрел всю ветку, но не нашел хотя бы примерных цифр по зп... что я упустил?
   Новиков
 
265 - 12.04.18 - 12:34
(263) совершенно верно. Представь - есть конфа, ее купили, челы там сами варятся. Они привыкли, что в каких-то отчетах, где есть такая возможность - можно фильтроваться по типу. Но в любом произвольном отчете (согласно логике здравого смысла, конечно) - они по типу отфильтроваться не могут, т.к. они понятия не имеют, что есть конфигуратор, есть отчет, его как-то надо там открыть, что-то сделать и т.д. и т.п. Коробочный отбор (типа коробочный) при отборе по типу показывает болт. Т.е. без движений специалиста по внедрению или программиста, такой отбор пользователь не сделает. Вот в чем трабл.

(264) Анна, эйчар этой конторы, не считает правильным озвучивать вилку, т.к. с ее личной точки зрения, это бестолковое занятие и бессмысленное. Если у тебя есть желание, можешь сам первый ценник в почту ей скинуть, и она тебе скажет - ты угадал или нет. Таковы реалии, друже :)
   Genayo
 
266 - 12.04.18 - 12:36
(264) Цифр нет. Они не хотят, чтобы другие сотрудники знали уровни зарплат программистов 1С, и завидовали :)
   Cyberhawk
 
267 - 12.04.18 - 12:43
(265) Кстати, такое пожелание для СКД у 1С, с их слов, давно записано :)
https://partners.v8.1c.ru/forum/t/1502045/m/1580932
   _stay true_
 
268 - 12.04.18 - 12:51
(264) Лотерея.
Я сознательно игнорировал вакансии, где з/п не указана.
   Так мало знающий
 
269 - 12.04.18 - 12:52
(264) Что? Забыли времена когда 1С-ники работали за доширак? Так вот они вернулись.
   Новиков
 
270 - 12.04.18 - 12:54
(267) я в курсе :) Поэтому и предположил, что возможно в .12 это уже есть. Но судя по описанию, нет. Кстати, выше показывалось что отбор в запросе по ССЫЛКА и ТИПЗначения = Тип одинаков на уровне СУБД. Это с 8.3.6 началось.
   Вафель
 
271 - 12.04.18 - 12:54
(269) Никогда такого не было
   Cyberhawk
 
272 - 12.04.18 - 14:20
(270) "отбор в запросе по ССЫЛКА и ТИПЗначения = Тип одинаков на уровне СУБД. Это с 8.3.6 началось" // Раньше тоже вроде одинаков всегда "результирующий" запрос был в обоих случаях
   Anna-recruiter
 
273 - 12.04.18 - 15:18
(264) Игорь, добрый день! Если вакансия Вам интересна,пожалуйста, присылайте резюме на Anna.Krasner@ottoruss.ru. Я буду рада ответить на Ваши вопросы, обсудить вакансию и компенсацию.
   Вафель
 
274 - 12.04.18 - 15:19
а кстати почему обеденный перерыв всего 45мин?
   Cyberhawk
 
275 - 12.04.18 - 15:27
(274) Видимо потому что в пятницу сокращенный день )
   Локи-13
 
276 - 12.04.18 - 15:46
(264) Это аукцион. Продавцы кидают резюме и цену, а покупатель выберет наиболее выгодное предложение.
   bolobol
 
277 - 12.04.18 - 15:46
(275) Тогда, перерыв должен быть 48 минут, а не 45. Где три минуты?
   Cyberhawk
 
278 - 12.04.18 - 15:55
(277) Три минуты за день, 15 минут в неделю ворует работодатель у РАБотника
   Новиков
 
279 - 12.04.18 - 17:26
(272) не всегда. Что-то переделывали, ведь не спроста несколько лет об этом где с ссылка трубилось везде :)
   Cyberhawk
 
280 - 12.04.18 - 17:45
(279) А где например об этом говорилось?
   Новиков
 
281 - 13.04.18 - 10:51
(280) в апдейтах к платформе в 8.3.6 косвенно вброс есть на эту тему. Про где ссылка - статьи были на итс тех периодов, ну и опять же косвенно, не зря ж грабли вышеописанные всплыли про где ссылка в запросе к параметру в виде таблицы, при неизвестном (в общем случае) типа. Почему то так же сделано в некоторых местах в типовых и на это обращали внимание. Скорее всего - тоже привели к рекомендации. Но если что - это не более чем гипотеза, может просто челу так было удобнее :)
   _stay true_
 
282 - 13.04.18 - 11:18
(276) Или а-ля Джон Краммер: "Привет, я хочу сыграть с тобой в одну игру "угадай вилку".
   mistеr
 
283 - 13.04.18 - 13:11
Ну что, кто-нибудь уже прикиньтесь кандидатом и озвучьте нам вилку.
   Aerosmith
 
284 - 17.04.18 - 09:40
(276) >Это аукцион. Продавцы кидают резюме и цену, а покупатель выберет наиболее выгодное предложение.

Подобная схема называется тендер. В аукционе наоборот, идет повышение цены.
   palsergeich
 
285 - 20.04.18 - 17:38
(234) Есть очень тонкий ньюансы:
1) Для каждого количества в списке будет формироватся свой план запросов, что в итоге может приводить к переполнению кэша плана запросов и можно получить нехилую нагрузку где не ждали (а может и не приводить)
2) При количестве элементов в списке более 1000 происходит следующая трансформация: Список предварительно загружается в Таблицу и потом идет уже соединение с таблицей, а не where.
   PR
 
286 - 20.04.18 - 18:38
(86) Какая прелесть :))
   Krendel
 
287 - 20.04.18 - 18:47
Что-то фабрикант мышей вообще не ловит
   Krendel
 
288 - 20.04.18 - 18:48
в тематических ветках обсуждение запросов
   PR
 
289 - 20.04.18 - 18:49
(287) Ушел в запой на радостях
   Jofa
 
290 - 21.04.18 - 00:09
Без фотки не взлетит!
   Sinoptic
 
291 - 23.04.18 - 09:03
   Сияющий в темноте
 
292 - 23.04.18 - 09:37
Видимо,им 1сники желаемые зарплаты прислали
   systemstopper
 
293 - 23.04.18 - 11:25
(285) Не смог пройти мимо, т.к. всё сказанное абсолютнейшая дичь:
1. Не будет. План зависит от количества значений в IN по определенной логике, например до 16 констант в IN будет  scan, от 16 до 65 filter + scan. А больше 65 будет сканирование таблицы констант и вложенные циклы с соединяемой таблицей к которой будет seek. И все варианты работают нормально. И никакого переполнения кэша (это вообще без комментариев) не будет.
2. См. п. 1.
   palsergeich
 
294 - 02.05.18 - 21:30
(293) В обще - то будет, на обучении кстати приводятся все примеры. Под каждое количество параметром создается свой план запроса, что может и на реальных системах иногда приводит к переполнению кэша плана запросов.
Во вторых поведение оператора В зависит от релиза платформы, ранее оно было действительно от 65, но потом это число увеличили.
Было забавное видео от суровых MSSQL админов, в котором данная фича обсуждалась, там при различии текста запроса на символ формируется новый план запроса.
Вот статейка в тему http://www.queryprocessor.ru/fast-in-ssms-slow-in-app-part3/
   palsergeich
 
295 - 02.05.18 - 21:35
И да на реальных системах бездумное применение данного оператора может приводить к латчам.
   palsergeich
 
296 - 02.05.18 - 21:42
(101) единственный вариант без использования сторонних утилит - EDT + GIT. Ну соответственно разрабатывая в разных ветках реально вести параллельную работу, и потом произвести слияние.
Наверное от старшего разработчика хотели широкий кругозор и знание современных трендов, на том же ИС вроде как отписывались люди которые небольшие проекты уже полностью на EDT перевели.
   H A D G E H O G s
 
297 - 02.05.18 - 21:44
(293) Чет какая-то дичь
   H A D G E H O G s
 
298 - 02.05.18 - 21:45
(293) ms sql server страшно логичная штука, в которую "до 16 констант в IN будет  scan" никак не укладывается
   systemstopper
 
299 - 04.05.18 - 15:28
(294) Ты всё смешал в кучу. Похоже наблюдается эффект от обучения людьми из 1С, которые сами в этом ничего не понимают.

1. >Под каждое количество параметром создается свой план запроса

Не создается. Читаем пост того же Пилюгина http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1082155&msg=15712697

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

>что может и на реальных системах иногда приводит к переполнению кэша плана запросов.

Что значит переполнение? Старые планы из кэша планов вытесняются новыми. В скуле есть отдельная оптимизация для ad hoc запросов, но для 8.3 это неактуально, т.к. ввели переиспользование пула временных таблиц.

2. >Во вторых поведение оператора В зависит от релиза платформы, ранее оно было действительно от 65, но потом это число увеличили.

речь вроде бы про запрос SQL, и его план, при чем здесь платформа?

3. >Было забавное видео от суровых MSSQL админов, в котором данная фича обсуждалась, там при различии текста запроса на символ формируется новый план запроса.

Какая фича? Какое отношение это имеет к 1С, которая тексты запросов генерирует автоматически и не может  поставить лишний пробел или написать разным регистром?

4. >Вот статейка в тему http://www.queryprocessor.ru/fast-in-ssms-slow-in-app-part3/

Статья не имеет к кол-ву параметров и влияние на планы вообще никакого отношения.
   systemstopper
 
300 - 04.05.18 - 15:28
  1  2  3  4   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
В секцию Вакансии можно добавлять сообщения только после регистрации на форуме.
Если вы уже зарегистрированы, вам нужно войти на форум.
Рекламное место пустует