Имя: Пароль:
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
Главное, чтобы после замены ИЛИ на объединение не получилось, что сервер выполняет вместо одного полного сканирования несколько.
Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Эдвард Йодан