Имя: Пароль:
1C
1С v8
Использование "ИЛИ" в условии запроса.
0 Goggy
 
25.02.15
12:10
Простенький вопросик для знатоков от зрителей :)
Почему настоятельно не рекомендуется использовать оператор ИЛИ в условии запроса?
1 Ник второй
 
25.02.15
12:10
Оптимизатор свихнется и построит не оптимальный план запроса
2 Ёпрст
 
25.02.15
12:10
кем ?
3 Ник второй
 
25.02.15
12:11
(2) здравым смыслом
4 ejikbeznojek
 
25.02.15
12:14
А я регулярно использую 8(
5 ejikbeznojek
 
25.02.15
12:15
ЗаявкаНаОтгрузкуНакладные.ВидНакладной <> "ЗТО"
ИЛИ
(ЗаявкаНаОтгрузкуНакладные.ВидНакладной = "ЗТО" И ЗаявкаНаОтгрузкуНакладные.Накладная.Отправитель = &Отправитель)
6 ejikbeznojek
 
25.02.15
12:17
Наверное можно всё сделать через
Выбор Когда тогда. Но вроде и так ни каких проблем нет.
7 Goggy
 
25.02.15
12:17
(1) Можно пример?
8 Ненавижу 1С
 
гуру
25.02.15
12:19
(7) непонятно ему какой индекс использовать
9 Ник второй
 
25.02.15
12:20
Использование логического ИЛИ в секции ГДЕ запроса

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.
Например, запрос

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

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

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"
10 Goggy
 
25.02.15
12:22
(9) Отличный и понятный ответ. Благодарю.
11 ДенисЧ
 
25.02.15
12:23
Просто 1сники криво нарисовали парсер запросов.
12 ejikbeznojek
 
25.02.15
12:23
Присоединюсь к благодарности))
13 Ник второй
 
25.02.15
12:25
(11) Ха ха... то есть сервер 1С должен был сам заменить запрос на объединение? а если там более одного ИЛИ? )))
14 Гёдза
 
25.02.15
12:26
(9) как раз такой запрос на раз-два оптимизатором щелкается.
А вот запросы
т.Артикул = &1 ИЛИ т.Наименование = &2
Вот тут, да
15 Гёдза
 
25.02.15
12:27
речь конечно не про файловую базу
16 kosts
 
25.02.15
12:27
Можно подумать что сервер такой глупый, что всегда будет строить не оптимальный план. Но сложные случаи возможно ему нужно помочь.
17 hhhh
 
25.02.15
12:29
то есть если используется не физическая таблица бд в запросе, то или спокойно можно применять?
18 kosts
 
25.02.15
12:31
(17) Временные тоже можно индексировать
19 mikecool
 
25.02.15
12:33
(13) нет, он должен подставить правильные хинты
20 Simod
 
25.02.15
12:34
(11) Окончательный план запроса строит СУБД.
21 H A D G E H O G s
 
25.02.15
12:48
(9) Бред.
22 H A D G E H O G s
 
25.02.15
12:50
(9) Классические пример:
a) Кривости RTFM от 1С.
б) Варианта, когда использование ИЛИ безопасно.
в) Шаблонности мышления 1С ников.
23 H A D G E H O G s
 
25.02.15
12:52
(8) Все ему понятно.
Посмотрит статистику и какой-нибудь использует.

(8) Можно твое имя и фамилию, пожалуйст. Для летописи.
24 PR
 
25.02.15
12:54
(22) Аргументируешь?
25 Ник второй
 
25.02.15
12:55
(22) В каком месте бред

И да автор того поста: Рупасов Константин (1С, Москва)
26 Ненавижу 1С
 
гуру
25.02.15
12:55
(23) чей-то?
27 H A D G E H O G s
 
25.02.15
12:57
(24) Зачем? Итак все логично и понятно - будет 2 индексных поиска.
(25) Я знаю, кто автор.
28 skeptik_m
 
25.02.15
12:58
(23) Ходят упорные слухи, что там где оптимизатор MS SQL еще справляется (хотя и без гарантии) оптимизаторы других СУБД (включая Oracle) впадают в ступор. Возможны и обратные случаи, но авторы типовых и прочих тиражируемых решений сидят на MS SQL, поэтому такие проблемы нетипичны.
29 H A D G E H O G s
 
25.02.15
12:58
(28) Особенно Oracle.
30 PR
 
25.02.15
13:00
(27) То есть Рупасов лох?
31 skeptik_m
 
25.02.15
13:02
(29) А в 1С хотят, чтобы работало на всех поддерживаемых СУБД более менее прилично. Поэтому выдвигают рекомендации писать запрос так, чтобы самый негодный оптимизатор справлялся удовлетворительно, а не только самый годный в случае если повезет.
32 skeptik_m
 
25.02.15
13:03
(31) А на трудоемкость им плевать - не их проблемы - работай, одноэсник работай, днем и ночью.
33 H A D G E H O G s
 
25.02.15
13:04
(30)
То есть нельзя никому верить, Печенкин Роман.
Надо все проверять, ставить под сомнение и пытаться докопаться до сути.
Как бы тебя не слепил красный кожаный, блестящий на солнце, плащъ.
34 H A D G E H O G s
 
25.02.15
13:04
(31) В 2008 году, когда писался текст (9) - был ли Oracle?
35 PR
 
25.02.15
13:07
(33) Ну я как бэ согласен, хорошо.
Но хотелось бы некоторого веса словам.
А то получается, Рупасов сказал А, ты сказал Б.
Но Рупасов все-таки сказал на ИТС всей России, а ты на МиСте узкому кругу.
Спрашивается, как решить, кто прав, кто нет.
Может, моделирование ситуации решит спор? :))
36 H A D G E H O G s
 
25.02.15
13:09
(35) Да.
37 Homer
 
25.02.15
13:12
ВЫбрать
Истина
Где 1 В (1,2)
40 H A D G E H O G s
 
25.02.15
13:14
ВЫБРАТЬ
    Номенклатура.Артикул
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.Артикул = &Артикул1
    ИЛИ Номенклатура.Артикул = &Артикул2
41 H A D G E H O G s
 
25.02.15
13:14
42 H A D G E H O G s
 
25.02.15
13:16
(26) Нужно Коля, нужно.
43 Лефмихалыч
 
25.02.15
13:20
(22) б - если условия на поля составного типа, то план запроса действительно может отличаться эпическим образом. Даже со всеми возможными ВЫРАЗИТЬ. Проверено на себе.
44 H A D G E H O G s
 
25.02.15
13:23
(43) Планы НИКОГДА не бывают нелогичными и не вылезают ВНЕЗАПНО. Всегда есть причина, по которой sql выбрал этот план, надо просто долго ковырять.
45 H A D G E H O G s
 
25.02.15
13:24
"Оптимизатор SQL ошибся"

Годный 1Сник никогда не должен говорить эту фразу.
46 PR
 
25.02.15
13:25
(41) Ну то есть типа опровергли ИТС и Рупасова?
47 Ник второй
 
25.02.15
13:25
(46) Нет
48 Лодырь
 
25.02.15
13:26
(45) Он может не ошибаться, а добросовестно заблуждаться. Причина разумеется будет, только станет ли лучше от этого результат?
49 Ник второй
 
25.02.15
13:28
(48) Ошибаются все, даже оптимизаторы
50 Лодырь
 
25.02.15
13:29
(49) Программа ошибаться не может, может ошибаться ее разработчик )
51 Лефмихалыч
 
25.02.15
13:30
(44) я вроде ни где не сказал, что причины не было.
и ты в бутылку лезешь
52 H A D G E H O G s
 
25.02.15
13:30
(46) Рупасов привел годный совет, но негодный пример :-)
53 Ник второй
 
25.02.15
13:30
(51) +100500 ))))
54 H A D G E H O G s
 
25.02.15
13:33
(51) Звучало так, как будто при использовании составных полей может случиться НЕХ.
55 H A D G E H O G s
 
25.02.15
13:36
Лучше бы они просто дали ссылку на эту статью.
http://www.sql.ru/articles/mssql/2007/012302seekpredicates.shtml
56 Лефмихалыч
 
25.02.15
13:37
(54) это только в твоей голове так звучало. deal with it
57 Ненавижу 1С
 
гуру
25.02.15
13:38
сравнил на 1000 прогонах

ВЫБРАТЬ
    Продажи.Период,
    Продажи.Номенклатура,
    Продажи.Количество
ИЗ
    РегистрНакопления.Продажи КАК Продажи
ГДЕ
    (Продажи.Номенклатура = &Номенклатура1
            ИЛИ Продажи.Номенклатура = &Номенклатура2)

и вот такой:

ВЫБРАТЬ
    Продажи.Период,
    Продажи.Номенклатура,
    Продажи.Количество
ИЗ
    РегистрНакопления.Продажи КАК Продажи
ГДЕ
    (Продажи.Номенклатура = &Номенклатура1)
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
    Продажи.Период,
    Продажи.Номенклатура,
    Продажи.Количество
ИЗ
    РегистрНакопления.Продажи КАК Продажи
ГДЕ
    (Продажи.Номенклатура = &Номенклатура2)

практической разницы не замечено
58 Ник второй
 
25.02.15
13:40
(57) Ты разницу чего искал?
59 Ненавижу 1С
 
гуру
25.02.15
13:43
(58) времени выполнения
60 H A D G E H O G s
 
25.02.15
13:43
(58) Щупал радиатор процессора.
61 Ник второй
 
25.02.15
13:44
(59) И что это означает? )))
62 H A D G E H O G s
 
25.02.15
13:45
(61) Сходил на семинар и все можно?
Что этот 1Снег себе позволяет?
63 samozvanec
 
25.02.15
13:51
(62) для тех кто не ходил на семинар, а что там у нас с кешированием в (57)?
64 Ник второй
 
25.02.15
13:55
Запрос с простым И

"result  (cost=0.00..4.08 rows=1 width=19) (actual time=0.000..0.000 rows=0 loops=1)
  one-time filter: false
  ->  index only scan using _docum10341_bydocnum_sr on Документ.XXXXXXXXXX t1  (cost=0.00..4.08 rows=1 width=19) (never executed)
        index cond: (Номер = '000000011'::mvarchar)
        heap fetches: 0
total runtime: 0.018 ms
"

"limit  (cost=0.00..4.09 rows=1 width=0) (actual time=0.023..0.023 rows=0 loops=1)
  ->  index scan using pg_class_relname_nsp_index on pg_class  (cost=0.00..4.09 rows=1 width=0) (actual time=0.022..0.022 rows=0 loops=1)
        index cond: (relname = 'tt82'::name)
        filter: (pg_table_is_visible(oid) and (relkind = 'r'::""char""))
total runtime: 0.040 ms
"

Вместо И установил ИЛИ


"bitmap heap scan on Документ.XXXXXXXXXX t1  (cost=4.15..8.11 rows=2 width=19) (actual time=1.536..1.539 rows=2 loops=1)
  recheck cond: ((Номер = '000000011'::mvarchar) or (Номер = '000000010'::mvarchar))
  ->  bitmapor  (cost=4.15..4.15 rows=2 width=0) (actual time=1.530..1.530 rows=0 loops=1)
        ->  bitmap index scan on _docum10341_bydocnum_sr  (cost=0.00..2.07 rows=1 width=0) (actual time=1.517..1.517 rows=1 loops=1)
              index cond: (Номер = '000000011'::mvarchar)
        ->  bitmap index scan on _docum10341_bydocnum_sr  (cost=0.00..2.07 rows=1 width=0) (actual time=0.012..0.012 rows=1 loops=1)
              index cond: (Номер = '000000010'::mvarchar)
total runtime: 1.560 ms
"

"limit  (cost=2.10..9.61 rows=1 width=0) (actual time=0.037..0.037 rows=0 loops=1)
  ->  bitmap heap scan on pg_class  (cost=2.10..9.61 rows=1 width=0) (actual time=0.036..0.036 rows=0 loops=1)
        recheck cond: (relname = 'tt35'::name)
        filter: (pg_table_is_visible(oid) and (relkind = 'r'::""char""))
        rows removed by filter: 2
        ->  bitmap index scan on pg_class_relname_nsp_index  (cost=0.00..2.10 rows=4 width=0) (actual time=0.010..0.010 rows=7 loops=1)
              index cond: (relname = 'tt35'::name)
total runtime: 0.054 ms
"
65 H A D G E H O G s
 
25.02.15
13:58
(64) Еретический план запроса.
Тебя надо предать анафеме.
66 Ник второй
 
25.02.15
13:59
А вот объединить все

"result  (cost=0.00..8.15 rows=2 width=19) (actual time=0.040..0.051 rows=2 loops=1)
  ->  append  (cost=0.00..8.15 rows=2 width=19) (actual time=0.040..0.051 rows=2 loops=1)
        ->  index only scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t1  (cost=0.00..4.08 rows=1 width=19) (actual time=0.039..0.039 rows=1 loops=1)
              index cond: (Номер = '000000011'::mvarchar)
              heap fetches: 1
        ->  index only scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t2  (cost=0.00..4.08 rows=1 width=19) (actual time=0.010..0.010 rows=1 loops=1)
              index cond: (Номер = '000000010'::mvarchar)
              heap fetches: 1
total runtime: 0.079 ms
"
67 Ник второй
 
25.02.15
14:01
(66) Не сложно заметить, что второй запрос работает чутка лучше )))
68 Ник второй
 
25.02.15
14:03
(65) у меня еще пачка логинов в запасе ))) пффффф
69 H A D G E H O G s
 
25.02.15
14:04
(66) Я правильно вижу indexscan в нем?
70 Ник второй
 
25.02.15
14:08
Index Scan — используется индекс для условий WHERE, читает таблицу при отборе строк.
Bitmap Index Scan — сначала Index Scan, затем контроль выборки по таблице. Эффективно для большого количества строк.

как я понимаю, в постгре чуть по другому идет работа с индексами
71 Ник второй
 
25.02.15
14:08
(70)
Index Only Scan выполняется быстрее, чем Index Scan за счёт того, что не требуется читать строку таблицы полностью
72 H A D G E H O G s
 
25.02.15
14:13
(70) (71) В сортах мммм. Постгрии не разбираюсь :-)
73 ShoGUN
 
25.02.15
14:24
(72) Ну зря ты так, из бесплатных СУБД, пожалуй, лучшая. То, что 1С её мучает - это проблема заточенности 1С под MS SQL Server(уже говорили в этой ветке).
74 Ник второй
 
25.02.15
14:24
Так выглядит не попадание в индекс, то есть дырка в индексах:

"aggregate  (cost=4.08..4.08 rows=1 width=19) (actual time=0.035..0.035 rows=1 loops=1)
  ->  index scan using _docum10341_bydocnum_sr on Документ.ХХХХХХХХХХ t1  (cost=0.00..4.08 rows=1 width=19) (actual time=0.022..0.025 rows=1 loops=1)
        index cond: (Номер = '000082891'::mvarchar)
        filter: (СтруктурнаяЕдиница = '\\x5d9a0007e932f60411e163a8025e9964'::bytea)
total runtime: 0.073 ms
"

то есть надо обращать внимание на постгре что бы было слово index cond и не было filter...

в майстайном сервере это seek ..... where
75 Ник второй
 
25.02.15
14:26
(72) Пока тоже не разбираюсь, но вот пришлось сталкнуться... даже пришлось собиратель плана запроса от 1С доработать, так как вся линейка продуктов 1С заточена на Win... А с линуксом отказывается работать
76 Ник второй
 
25.02.15
14:29
(73) Вполне добротно работает.... если бы не подножки , которые 1С подстроила, а именно отсутствие инструментария если субд расположена на линуксах
77 ShoGUN
 
25.02.15
14:42
(76) Ну кабы не работало - никто бы не пользовался )
78 vhl
 
25.02.15
16:14
(9) Да чепуха все это, к этим советам надо всегда относиться с известной долей скептицизма и проверять на реальных данных. Те советы писались в махровые 2000 годы такими же "спецами" как вы сами.
79 PR
 
25.02.15
16:55
(47) Что нет?
80 PR
 
25.02.15
16:56
(52) Приведи годный пример/
81 H A D G E H O G s
 
25.02.15
17:04
(80) см. (41) (42)
82 DirecTwiX
 
25.02.15
17:56
У меня пару раз возникал следующий вопрос..
Что будет со временем выполнения запроса, если условие с ИЛИ заменить на условие с И?

ГДЕ А ИЛИ Б
->
ГДЕ НЕ ((НЕ А) И (НЕ Б))

Есть знатоки?
83 Гёдза
 
25.02.15
17:59
(82) тоже самое
84 DirecTwiX
 
25.02.15
18:27
(83) Из-за оптимизатора запроса, который заменит ИЛИ на И?
85 1976vas
 
25.02.15
18:38
Битва гигантов, если честно очень познавательно. А вопрос (82) вообще +100500
86 tridog
 
25.02.15
20:10
(44) Только иногда этой причиной является timeout.
87 MrStomak
 
25.02.15
20:26
(44) В мире нет ничего ВНЕЗАПНОГО. Даже генератор случайных чисел генерирует не случайные числа и вообще вселенная детермеринована.
Однако, когда postgresql выбирает план, выполняющий запрос 30 минут,тогда как 5 лет до этого стабильно выбирал план, выполняющий запрос за 3 секунды - это почему-то оказывается ВНЕЗАПНО
88 Икогнито
 
25.02.15
20:27
(82) условие НЕ В (&Массив)
89 Икогнито
 
25.02.15
20:30
Чтобы не париться с планом запроса по условию ИЛИ, можно выбрать данные в временную таблицу, проиндексировать нужные поля, а потом фильтрануть ее.
90 MrStomak
 
25.02.15
20:31
(84) Ну представь себе телефонный справочник, представь, что надо выбрать всех не Ивановых и не Сергеев. Придется перебирать весь справочник фактически. Исключением будут являтся разве что логические типы, где НЕ вернет конкретное значение, которое можно сравнить на эквивалентность и использовать индекс по нему.
91 MrStomak
 
25.02.15
20:33
(89) Чтобы не париться с поиском организаций, у которых ИНН заканчивается на 351, я предлагаю переписать из справочника к себе в тетрадочку только те организации, у которых ИНН заканчивается на  351!!!
92 Икогнито
 
25.02.15
20:35
Еще можно обойти ИЛИ с помощью CASE When Then.
Скульщики говорят, что утверждение, что Case работает не используя индексы - лживое.
93 MrStomak
 
25.02.15
20:36
(92) Утверждение, что ИЛИ не использует индексы - тоже лживое.
94 Икогнито
 
25.02.15
20:38
(93) глубоко не знаю, но думаю, что построение плана запроса зависит от очень многих факторов. Начиная от собственной статистики скуля по обращению к таблицам и заканчивая их объемами, индексами и прочим.
95 H A D G E H O G s
 
25.02.15
20:40
(91) Прекрасно!
96 H A D G E H O G s
 
25.02.15
20:40
совет (89) прекрасно иллюстрирует всю сущщность "специалистов".
97 Икогнито
 
25.02.15
20:40
Сегодня с таблицей мало работают - план запроса один, завтра куча народу строит отчеты по таблице - план запроса другой.
98 H A D G E H O G s
 
25.02.15
20:41
(97) Бред.
99 MrStomak
 
25.02.15
20:42
(94) у скуля нет статистики по обращению к таблицам. Есть гистограммы распределения значений индексов, показывающая селективность запроса. Собственно, это и называется статистикой.
100 Икогнито
 
25.02.15
20:42
(96) (98) не буду спорить. Оставайся при своем мнении.
101 H A D G E H O G s
 
25.02.15
20:42
(94) План запроса зависит от незначительного числа факторов.
102 MrStomak
 
25.02.15
20:45
(101) Но эти незначительные факторы могут выливаться в сложные системы, в которых черт ногу сломит и сам оптимизатор забивает, потому что не успевает ниче придумать, и отдаёт всякую хрень.
103 Икогнито
 
25.02.15
20:45
(101) это многое объясняет
104 H A D G E H O G s
 
25.02.15
20:45
(99) Ты счаст ему ничего не сказал.
Надо показать табличку статистики и сказать, что для значения из этого диапазона будет выбрано примерно столько то X записей из всего объема Y.

Ну и показать запросы по полной выборке из всех таблиц при
Update statistics with fullscan
105 MrStomak
 
25.02.15
20:47
(104) Согласен, однако задачи обучить кого-то не стоит.
106 DirecTwiX
 
25.02.15
20:54
(90) >Придется перебирать весь справочник фактически
Т.е. про индексы при таком раскладе можно забыть?
107 MrStomak
 
25.02.15
20:57
(106) Если поле логического типа - нет. В остальных случаях - да. Умение быстро найти в куче нужный тебе элемент ничерта не помогает, когда тебе как раз он то и не нужен.
< или > позволяет гарантированно определить диапазоны с ненужными данными и отсечь их.
а <>....
108 MrStomak
 
25.02.15
21:04
(107) Ну и еще оговорюсь - все эти мои пассажи относятся не к НЕ, а к имено к <>, который зачастую там получается  в итоге
109 Икогнито
 
25.02.15
21:31
(106) раз тебе ивановых часто искать надо и их номера, то может механизм полнотекстового поиска тебе поможет в этом?
110 MrStomak
 
25.02.15
21:49
(109) Будь внимательнее - речь шла про подмену ИЛИ из конструкций НЕ и И
111 viraboy
 
25.02.15
21:57
я бы предложил товарищу в (0) почитать соответствующую литературу, но как, и многие тут, не хочу плодить дешевых и бестолковых конкурентов.
112 pescennius
 
25.02.15
22:10
(111) Тот которые пытается что то познать дешевым и бестолковым не будет.
113 Икогнито
 
25.02.15
22:12
(110) Без ИЛИ всегда можно обойтись, как и без Полного Внешнего Соединения. Есть масса вариантов и они уже описаны выше.
По своему опыту использую эти вещи крайне редко.
114 pescennius
 
25.02.15
22:14
(113) Правильно , ИЛИ можно заменить на объединить все.
115 Икогнито
 
25.02.15
22:16
(112) очень много ложных знаний и пафосных советчиков, владеющих ими, которые и не знания вовсе.
Хочешь что-то познать - надо читать авторитетную литературу.
116 pescennius
 
25.02.15
22:22
(115) Советчиков тоже надо слушать, они подталкиваю в верное направление. Ну и конечно книги и конечно самим потрогать...
117 Икогнито
 
25.02.15
22:22
:)
118 H A D G E H O G s
 
25.02.15
22:26
(109) Механизм полнотекстового поиска - этот ровно тот же механизм индексов, который строит индексы для всех подстрок строки.

Тоесть, есть у нас строка
"Индианаполис"
обычный индексный поиск построит для нее индекс для значения
"Индианаполиc"

Этот индекс будет использоваться для условия вида
ПОДОБНО "Индиана%"
но не для условий
ПОДОБНО "%полис"

Полнотекстовый индекс построит 100500 индексов, в т.ч. для слова
"полис"

и в случае поиска по условию
ПОДОБНО "%полис"
будет использован.

Но для обновления данных индексов нужно 100500 времени, поэтому это нечастый процесс.
119 Ненавижу 1С
 
гуру
25.02.15
22:38
(118) чем я тебя зацепил то?
120 Икогнито
 
25.02.15
22:38
(118) есть два индекса в механизме : основной - он долго строится и дополнительный.
Основной самый быстрый, формируется периодически регламентным заданием , а дополнительный - это медленный индекс, в него попадает оперативная информация.
Поиск осуществляется сначала в основном, потом в дополнительном.
Так называемое обновление данных - это слияние индексов с целью освобождения дополнительного.


http://www.vnedriupp.ru/index.php?content=8301
121 Икогнито
 
25.02.15
22:43
Полнотекстовый поиск - очень удобная фишка, если нужно выискивать всякий мусор.
Но, мля, встает проблема с отображением информации, которую другие видеть Не должны.
122 MrStomak
 
25.02.15
22:50
(115) Если бы ты сам читал - не писал бы всякого бреда.
123 Икогнито
 
25.02.15
22:52
(122) закусывай
124 Икогнито
 
25.02.15
22:55
(122) я, мля одинесом 14 лет занимаюсь. И добуя советчиков читал, которые сидят тут чтобы повыпендриваться
125 H A D G E H O G s
 
25.02.15
22:57
(124) Это печально.
126 H A D G E H O G s
 
25.02.15
22:58
(120) Это прекрасная статья. Которая не рассказывает про физику процесса. Физика остается черным ящиком.
127 Икогнито
 
25.02.15
23:01
(125) уже говорили как-то, что красота кода - это для убеленных сединами старцев. Которые не имеют вала задач и имеют много времени для медитаций.
128 H A D G E H O G s
 
25.02.15
23:03
(119) Ничем.
Ты просто забавный со своим ООП, null и, как оказалось, невежеством.
129 H A D G E H O G s
 
25.02.15
23:05
(127) Годный кот пишут фикси. Ибо они планируют с ним же работать. Кот "наотщепись" пишут фри-фра. Ибо "траванерасти".
Все просто.
130 H A D G E H O G s
 
25.02.15
23:07
(127) Это печально - это к 14 годам.
К 14 годам занятий 1С-ом нужно разбираться во ВСЕМ.
131 H A D G E H O G s
 
25.02.15
23:09
До недавнего времени я тоже щитал, что хорошо знаю 1С и инф. системы и они просты как молоток. Как оказалось - 1С - дочерта сложная штука и требует от прогера дозвизды знаний. Просто 95% прогеров об этом не знают.
132 Икогнито
 
25.02.15
23:09
(129) завидую тебе, есть время на медитации и вникание в физику процессов...
133 H A D G E H O G s
 
25.02.15
23:09
(132) Лучше день потерять, потом за 5 минут долететь.
134 Икогнито
 
25.02.15
23:11
(133) ответь мне на вопрос один.
Ты сидишь наверно начальником, ковыряешься в носу и имеешь массу свободного Времени чтобы сидеть на мисте и с высоты своего положения троллить обычных работяг?
135 H A D G E H O G s
 
25.02.15
23:17
(134) Ну, юридически я простой программист.
В мисту погружен, но не критично.
Время есть, потому что:
1) Быстро и без ошибок пишу в своих конфах.
2) Часто работаю дома, по ночам, над несложными/интересными задачами.
136 H A D G E H O G s
 
25.02.15
23:18
(134) Троллить невежественных 1Сников считаю за долг, невежественные 1Сники бросают тень на блистательный образ автоматизаторов Отечества.
137 ShoGUN
 
25.02.15
23:19
(136) Брось, у тебя мания величия :) Троллить и без тебя есть кому.
138 GedKo
 
25.02.15
23:19
(133) +1

даже больше, лучше один раз и неделю потерять - зато потом некоторое время быстро знать как правильно.
139 H A D G E H O G s
 
25.02.15
23:21
(137) Не мешай троллить :-)
140 Икогнито
 
25.02.15
23:22
(135) работаю на такой работе, где 60% процентов задач надо по 2-3 раза переделывать. Потому, что постановшику задач глубоко пофигу на то, сколько раз будет переделываться работа, а Заказчик сам часто не знает что ему нужно и связи с ним нет.

Если в такой ситуации изучать индексы, ковыряться в носу и медитировать, то обычный отчет будешь делать месяц.
141 ShoGUN
 
25.02.15
23:25
(140) Ты вроде тут пытался выпендриться знаниями, а теперь оправдываешься, что времени нет, а потому нет и знаний. Ну ок, но обычно в такой ситуации умные люди слушают и вопросы задают, полезней выходит.
142 H A D G E H O G s
 
25.02.15
23:26
"Если в такой ситуации изучать индексы, ковыряться в носу и медитировать, то обычный отчет будешь делать месяц"

Нет.
Раз 5 заставь себя прогнать свеженаписанный отчет через профайлер, поправь правильно - потом автоматом будешь прикидывать. как правильно писать. Но все равно через профайлер всегда прогонять надо.

Твой отчет неспешно выполниться и пользователя вполне устроит, при этом забьет кэш и нагрузит диск и проц для других юзеров. Мелочь, но когда такие отчеты будут везде...
143 Икогнито
 
25.02.15
23:30
(141) знаний у меня достаточно для решения задач, которые ставит передо мной работодатель. Это подтверждает мой успешный стаж работы этой области в течении 14 лет.

А то, что вы тут сидите и троллите, говорит о том, что тут тусит масса скучающих бездельников, которые нифига толкового не делают и от безделья трассируют каждый запрос в скуле и теоретизирующих о высших материях там, где их нет.
144 H A D G E H O G s
 
25.02.15
23:31
Че тут думать, тут прыгать надо...
145 ShoGUN
 
25.02.15
23:33
(143) Ну как бы у меня тоже 10 лет опыта, и что с того? Я точно знаю, что я многого не знаю, но стремлюсь это устранить. Гонор ещё никому не помогал.
146 Икогнито
 
25.02.15
23:34
(145) сколько помню хадгенога на мисте - вечно в душу нагадить желает.
147 H A D G E H O G s
 
25.02.15
23:34
В этом году мне будет 9 лет :-0
148 Икогнито
 
25.02.15
23:34
А помню его почти с основания мисты
149 H A D G E H O G s
 
25.02.15
23:35
** помнят! чертяки!
150 GedKo
 
25.02.15
23:36
(143) чтобы обслуживать/дописывать базу ларька конечно же ничего особого не нужно :)
151 Икогнито
 
25.02.15
23:38
(150) я бы твою базу ларька дописывал красиво. Там делать некуй и переписывать код по пять раз не надо.
152 ShoGUN
 
25.02.15
23:39
(151) Я не понял, ты гордишься, что код по 5 раз переписываешь?
153 H A D G E H O G s
 
25.02.15
23:39
Я основной код наших доработок, оставшихся за предыдущими прогами (связаный с проведением РТУ) переписывал раза 3. Каждый раз считая, что вышла мммм, конфетка.
154 GedKo
 
25.02.15
23:41
(151) у меня нет базы ларька :( но, тебе бы доверил :)
155 Икогнито
 
25.02.15
23:43
(152) есть такая работа, платят от 200 тыр. Но главное условие: будь готов выкинуть в мусорку результат недельной работы и стараний и начать заново.
156 ShoGUN
 
25.02.15
23:44
(155) Депутат?
157 H A D G E H O G s
 
25.02.15
23:56
Диллема...
Продать совесть за 200 тыр.

Встречайте новый роман Д. Донцовой "Последнее искушение 1Сника", "Продажный код", "Черный властелин 1С. Годы молодости".
158 К_Дач
 
26.02.15
00:15
вот жеж... вон оно че, Михалыч! надо видимо, брать толстую книжку по sql и читаааать....

так в итоге то как лучше сложные условия использовать в "ГДЕ.."?

Вот еще что меня всегда волновало в условиях запроса. Есть выражение А ИЛИ Б. Причем мы заранее знаем, что А верно в 99 процентов случаев, а Б только в 1 проценте. Я верно понимаю, что порядок логических выражений имеет роль и "А ИЛИ Б" отработает быстрее, чем "Б ИЛИ А" ???
159 viktor_vv
 
26.02.15
01:00
(158) нет, порядок написания не важен.
160 Сти
 
26.02.15
08:15
(159) уточнение - в большинстве случаев не важен, планировщик запроса сам по своей статистике разберется, какое условие лучше проверить первым. Но иногда ошибается, и тогда лучше указать ему хинт. Но это на самом SQL, в 1С это никак не сделать, к сожалению.

(158) Книжку по SQL, конечно же, лучше почитать. Можно также MSDN по SQL серверу поизучать, документацию на postgre и т.п. Все это может помочь при написании запросов в 1С, хотя на SQL-сервер они порой приходят в таком изуродованном виде, что... Впрочем, разработчиков платформы трудно в этом винить, поскольку трансляция языка 1С-эскуэл в нормальный несколько нетривиальный процесс, как мне кажется.
161 Torquader
 
26.02.15
19:51
Главное, чтобы после замены ИЛИ на объединение не получилось, что сервер выполняет вместо одного полного сканирования несколько.