О рынке грузчиков и программистов

[Mikhail Kimmelman]

http://yakov-sirotkin.livejournal.com/180906.html

Представьте рынок грузчиков, которым зарплату платят
не за перевезённые грузы, а за размер мускулов.
...
По-моему, программистов у нас всегда стараются набрать
с как можно большими бицепсами. А студент будет получать
ползарплаты, даже если на нём держится весь проект.

Миша

[isa i]

On 10.11.2011 13:23, Mikhail Kimmelman wrote:
> http://yakov-sirotkin.livejournal.com/180906.html
>
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫зёО©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
> ...
> О©╫О©╫-О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ нёО©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫ О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫?

--
isa mozes the katsman you know that we're too damn poor
isa at isa dot dp dot ua to keep you from the Gallows Pole
ICQ 397543186 no opportunity necessary no experience needed

[Yury Mukharsky]

On Thu, 10 Nov 2011 13:24:11 +0200, isa i wrote:

> On 10.11.2011 13:23, Mikhail Kimmelman wrote:
>> http://yakov-sirotkin.livejournal.com/180906.html
>>

>> Представьте рынок грузчиков, которым зарплату платят
>> не за перевезённые грузы, а за размер мускулов.
>> ...
>> По-моему, программистов у нас всегда стараются набрать
>> с как можно большими бицепсами. А студент будет получать
>> ползарплаты, даже если на нём держится весь проект.

> а как-бы гарантия, что если мешок будет достаточно большой,
> что пльограммер не всрется?

Это вопрос к набору, а не выплате зарплаты. А для выплаты существенно, что
"пиздеть - не мешки ворочать", а намного важнее.

Юра

[Alex Mizrahi]

> Это вопрос к набору, а не выплате зарплаты. А для выплаты существенно, что
> "пиздеть - не мешки ворочать", а намного важнее.

Оценить вклад объективно практически не реально. Подсчёт строк кода,
закрытых тикетов как правило приводит к жульничеству и ухудшению
качества кода, так что проще платить соответственно некоей абстрактной
ценности.
Которая определяется не только образованием, но и опытом работы и т.д.
Статистически маловероятно что чел с хорошим образованием, хорошими
отзывами с предыдущих мест и т.д. будет очень плохо работать. Его бы
выгнали.
Какие-то флуктуации конечно будут, но без них никак.

Я, кстати, наблюдал чела который очень быстро и старательно выполнял
задачи, но вот только после него приходилось полностью всё переписывать,
т.к. код был очень говенным: глюкавым, дырявым, не-расширяемым,
не-поддерживаемым. Он просто не понимал что такое говенный код и почему
это плохо. Хуле, поверхностно работает -- да и ладушки.
В конечном итоге его уволили, т.к. по сути одни убытки.

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

[Valery Lapenkov]

"Mikhail Kimmelman" {mikhail....@gmail.com}:

Миша опять марксиста процитировал.

В.Лапенков.

[isa i]

ну так можно пойти дальше: набрать две команды. кто первый
написал тому и профит.

[isa i]

это пять.

[isa i]

On 10.11.2011 13:34, Yury Mukharsky wrote:

кстати анекдот в тему:

Начальник встает и говорит:
- Наш Питон-девелопер вчера в пьяном виде завалил все наши сервера. Чем
будем его наказывать?
Из глубины комнаты кричит Стив (рост 185, вес 100 кг):
- А давайте я его вдарю!
- Нет, нельзя. У нас один такой девелопер. Еще убъешь его. Так как
накажем девелопера?
Опять тот же голос из глубины комнаты:
- А давайте я тестера вдарю! У нас их трое...

[Wheelosopher]

On Nov 10, 3:23 am, "Mikhail Kimmelman" <mikhail.kimmel...@gmail.com>
wrote:

А я то думал программистам черепа меряють сколько серого вещества в
человеке. Или объем живота - сколько пива в него поместится. А тут -
мускулы.. Это зачем ?

[Sergey Babkin]

On 11/10/2011 08:39 AM, Alex Mizrahi wrote:

> Я, кстати, наблюдал чела который очень быстро и старательно выполнял
> задачи, но вот только после него приходилось полностью всё переписывать,
> т.к. код был очень говенным: глюкавым, дырявым, не-расширяемым,
> не-поддерживаемым. Он просто не понимал что такое говенный код и почему
> это плохо. Хуле, поверхностно работает -- да и ладушки.
> В конечном итоге его уволили, т.к. по сути одни убытки.

Ну таки глюкавым, или работает?

-СБ

[Alex Mizrahi]

Я же написал -- поверхностно. То есть на первый взгляд вроде работает.
Если копнуть глубже -- уже не очень.

Спецификации НИКОГДА не бывают полными, т.к. полная спецификация -- это
уже программа. (И то не факт...) Не-тривиальный код НИКОГДА не лишён
дефектов полностью.

Т.о. "работает", как такового, практически не существует. Можно лишь a
posteriori, то есть после эксплуатации, сказать хорошо оно работало или
плохо. Разумеется, на момент закрытия тикета оно не ясно.

Разумеется, в спецификации задачи нигде не будет сказано, что код не
должен содержать SQL injection, XSS и CSRF уязвимостей, должен работать
за приемлимое время и т.д. Это подразумевается. Потому что в противном
случае приложение нафиг не нужно.

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

При этом зачастую даже не обязательно специально думать над
формулировкой задачи, достаточно просто реализовать её с соблюдением
всех рекомендаций и опыта. К примеру, простой отказ от использования
error-prone технологий в пользу профессиональных, проверенных
фреймворков и библиотек позволит исключить SQL injection, XSS и CSRF,
нормальному человку просто в голову не прийдёт сделать иначе.

А ненормальный сделает по-старинке, SQL запросы с помощью конкатенации
строк, как в древних туториалах. (Реальный случай, кстати.)

То есть, потыкать кнопки -- работает. Открываешь код -- там ппц.

А потом на рабочей базе данных начинаются тормоза. А что, никто ведь не
требовал оптимизировать, да?

Опять же, вменяемый человек напишет код так, чтобы избегать раундтрипов
по сети, O(N^2) и O(2^N) алгоритмов там где это можно избежать, а
дуболом сделает как ему удобнее.

[Const]

Alex Mizrahi <alex.m...@gmail.com> wrote:
> А ненормальный сделает по-старинке, SQL запросы с помощью конкатенации
> строк, как в древних туториалах. (Реальный случай, кстати.)

А что такое "SQL запросы с помощью конкатенации строк" ?

---
Const

[dva]

"Const" <oc...@optonline.net> сообщил/сообщила в новостях следующее:
news:j9jli1$oe1$3...@aspen.stu.neva.ru...

>
> А что такое "SQL запросы с помощью конкатенации строк" ?

Это когда из много-много коротких предложений делают одно очень длинное
предложение.

[Юpa Шaлaк]

"Const" <oc...@optonline.net> wrote in message
news:j9jli1$oe1$3...@aspen.stu.neva.ru...

Это за что руки отрывать нужно в большинстве случаев.
С другой стороны, бездумное использование Hibernate - ничем не лучше.
Так что платить нужно исключительно за "мускулы".

[Alex Mizrahi]

>> А ненормальный сделает по-старинке, SQL запросы с помощью конкатенации
>> строк, как в древних туториалах. (Реальный случай, кстати.)

> А что такое "SQL запросы с помощью конкатенации строк" ?

$query_sql = "SELECT * FROM users WHERE user_id = " . $user_id;
//конкатенация!
$res = mysql_query($query_sql);


А надо так: "SELECT * FROM users WHERE user_id = $1" -- prepared
statement. Затем он вызывается с параметром в котором конкретное число
или строка. В идеале оно даже типизовано и не сериализуется в строку.

[Const]

Ага, я очень приблизительно понял, о чём речь.

А можно узнать, в каких именно древних туториалах
рекомендуется делать "по старинке" ?

---
Const,
знакомый с Pro*C и его древними туториалами,
начиная где-то с оракла версии 5.

[Victor Alekhin]

On 11/12/11 4:27 AM, Const wrote:
> Alex Mizrahi<alex.m...@gmail.com> wrote:
>>>> А ненормальный сделает по-старинке, SQL запросы с помощью конкатенации
>>>> строк, как в древних туториалах. (Реальный случай, кстати.)
>
>>> А что такое "SQL запросы с помощью конкатенации строк" ?
>
>> $query_sql = "SELECT * FROM users WHERE user_id = " . $user_id;
>> //конкатенация!
>> $res = mysql_query($query_sql);
>
>> А надо так: "SELECT * FROM users WHERE user_id = $1" -- prepared
>> statement. Затем он вызывается с параметром в котором конкретное число
>> или строка. В идеале оно даже типизовано и не сериализуется в строку.
>
> Ага, я очень приблизительно понял, о чём речь.
>
> А можно узнать, в каких именно древних туториалах
> рекомендуется делать "по старинке" ?

За sql в приложении надо гнать в шею,
приложение должно отправлять параметры
и получать от дб результат.

[Alex Mizrahi]

> А можно узнать, в каких именно древних туториалах
> рекомендуется делать "по старинке" ?

PHP+MySQL, там параметризованные запросы отсутсвовали на уровне АПИ.
Многие PHP программисты начинали оттуда, и оттуда растут типичные
проблемы PHP сайтов.

Да и сейчас MySQL поддерживает параметры только для prepared statement,
а они не имеют смысла в PHP, так что некоторые их эмулируют на уровне
API доступа к БД.

[Sergey Babkin]

On 11/11/2011 10:27 PM, Const wrote:
> Alex Mizrahi<alex.m...@gmail.com> wrote:
>>>> А ненормальный сделает по-старинке, SQL запросы с помощью конкатенации
>>>> строк, как в древних туториалах. (Реальный случай, кстати.)
>
>>> А что такое "SQL запросы с помощью конкатенации строк" ?
>
>> $query_sql = "SELECT * FROM users WHERE user_id = " . $user_id;
>> //конкатенация!
>> $res = mysql_query($query_sql);
>
>> А надо так: "SELECT * FROM users WHERE user_id = $1" -- prepared
>> statement. Затем он вызывается с параметром в котором конкретное число
>> или строка. В идеале оно даже типизовано и не сериализуется в строку.
>
> Ага, я очень приблизительно понял, о чём речь.
>
> А можно узнать, в каких именно древних туториалах
> рекомендуется делать "по старинке" ?

Для одноразовых запросов - вполне ничего. Особенно если запрос генерится
динамически (типа, в одном случае добавляем одно where, в другом - другое,
в третьем - еще и group by присобачить). Всех делов - писать не
$user, а &enquote($user). Казалось бы, много ума не надо.

-СБ

[Const]

Alex Mizrahi <alex.m...@gmail.com> wrote:
> > А можно узнать, в каких именно древних туториалах
> > рекомендуется делать "по старинке" ?

> PHP+MySQL, там параметризованные запросы отсутсвовали на уровне АПИ.
> Многие PHP программисты начинали оттуда, и оттуда растут типичные
> проблемы PHP сайтов.

То-то Сол так забеспокоился.

> Да и сейчас MySQL поддерживает параметры только для prepared statement,
> а они не имеют смысла в PHP, так что некоторые их эмулируют на уровне
> API доступа к БД.

Ужас какой.

---
Const

[Юpa Шaлaк]

"Sergey Babkin" <sab...@hotmail.com> wrote in message
news:j9n6c...@news4.newsguy.com...

Для MySQL - сойдет, конечно. А вот у взрослых (типа MS SQL) это приводит к
тому, что на каждый запрос генерируется свой execution plan. При
параметризации -
даже при динамической сборке WHERE и других clauses - использование
переменных может серьезно улучшить производительность.

[Sergey Babkin]

При динамической сборке операторы будут каждый раз разные. Так что
в любом разе будут компилироваться сначала.

-СБ
задумываясь, с каких пор MS SQL стал считаться взрослым

[Victor Alekhin]

On 11/14/11 1:23 AM, Sergey Babkin wrote:
> On 11/13/2011 11:10 AM, Юpa Шaлaк wrote:
>>
>> "Sergey Babkin" <sab...@hotmail.com> wrote in message
>> news:j9n6c...@news4.newsguy.com...

>> Для MySQL - сойдет, конечно. А вот у взрослых (типа MS SQL) это
>> приводит к
>> тому, что на каждый запрос генерируется свой execution plan. При
>> параметризации -
>> даже при динамической сборке WHERE и других clauses - использование
>> переменных может серьезно улучшить производительность.
>
> При динамической сборке операторы будут каждый раз разные. Так что
> в любом разе будут компилироваться сначала.

sql должен жить в дб, все остальное от лукавого.

> -СБ
> задумываясь, с каких пор MS SQL стал считаться взрослым

Ну так и mysql некоторые называют db.

[Юpa Шaлaк]

"Sergey Babkin" <sab...@hotmail.com> wrote in message

news:j9pn1...@news2.newsguy.com...

Оно хешируется по тексту запроса. Грубо говоря
WHERE Price > 1
и
WHERE Price > 2
- разные, а вот

WHERE Price > @Price

всегда будет одним, пусть оно и динамически собралось.

>
> -СБ
> задумываясь, с каких пор MS SQL стал считаться взрослым

Я же сказал "взрослая", а не "заматерелая"

[Sergey Babkin]

Да? А вроде ж в ODBC запросы компилируются отдельно для каждой сессии.
Так что если там был такой же запрос в другой сессии, оно вряд ли
поможет. С другой стороны, конечно, если это какая-то веб-хрень,
и сессии держатся в пуле и выдаются обработчикам запросов по мере
необходимости на время, то поможет.

>> задумываясь, с каких пор MS SQL стал считаться взрослым
>
> Я же сказал "взрослая", а не "заматерелая"

Ну уж не взрослее mysql.

Кстати, я тут поимел опыт работы с Сайбейзом, так он оказался
с какой стороны не посмотри, гораздо тормознее Оракла.
А MS SQL - ответвление Сайбейза.

-СБ

[Юpa Шaлaк]

"Sergey Babkin" <sab...@hotmail.com> wrote in message

news:j9s44...@news4.newsguy.com...

> On 11/14/2011 02:52 PM, Юpa Шaлaк wrote:
>> "Sergey Babkin" <sab...@hotmail.com> wrote in message
>> news:j9pn1...@news2.newsguy.com...
>>> On 11/13/2011 11:10 AM, Юpa Шaлaк wrote:
>>>>

...

>>>> Для MySQL - сойдет, конечно. А вот у взрослых (типа MS SQL) это
>>>> приводит к
>>>> тому, что на каждый запрос генерируется свой execution plan. При
>>>> параметризации -
>>>> даже при динамической сборке WHERE и других clauses - использование
>>>> переменных может серьезно улучшить производительность.
>>>
>>> При динамической сборке операторы будут каждый раз разные. Так что
>>> в любом разе будут компилироваться сначала.
>>
>> Оно хешируется по тексту запроса. Грубо говоря
>> WHERE Price > 1
>> и
>> WHERE Price > 2
>> - разные, а вот
>>
>> WHERE Price > @Price
>>
>> всегда будет одним, пусть оно и динамически собралось.
>
> Да? А вроде ж в ODBC запросы компилируются отдельно для каждой сессии.

При чем тут ODBC? Я говорю о том, что будет происходить на сервере.

> Так что если там был такой же запрос в другой сессии, оно вряд ли
> поможет. С другой стороны, конечно, если это какая-то веб-хрень,

Конечно же поможет. Я же говорю об execution plan cache.

> и сессии держатся в пуле и выдаются обработчикам запросов по мере
> необходимости на время, то поможет.
>
>>> задумываясь, с каких пор MS SQL стал считаться взрослым
>>
>> Я же сказал "взрослая", а не "заматерелая"
>
> Ну уж не взрослее mysql.

Чего? mysql - это детская поделка на коленке по сравнению с.

> Кстати, я тут поимел опыт работы с Сайбейзом, так он оказался
> с какой стороны не посмотри, гораздо тормознее Оракла.
> А MS SQL - ответвление Сайбейза.

Я так понимаю, что кроме базового T-SQL у них давно не осталось ничего
общего.

[Sergey Babkin]

И на сервер запросы попадут как?

>> Так что если там был такой же запрос в другой сессии, оно вряд ли
>> поможет. С другой стороны, конечно, если это какая-то веб-хрень,
>
> Конечно же поможет. Я же говорю об execution plan cache.

Если запросы не совершенно тривиальны, у меня есть ощущение, что
компиляция запросов гораздо быстрее их исполнения.

>> и сессии держатся в пуле и выдаются обработчикам запросов по мере
>> необходимости на время, то поможет.
>>
>>>> задумываясь, с каких пор MS SQL стал считаться взрослым
>>>
>>> Я же сказал "взрослая", а не "заматерелая"
>>
>> Ну уж не взрослее mysql.
>
> Чего? mysql - это детская поделка на коленке по сравнению с.

Почему? Вот скажем Сайбейз и особенно IQ производят впечатление
детской поделки.

-СБ

[Alexander Veremyev]

On 16.11.2011 0:05, Sergey Babkin wrote:
> On 11/15/2011 10:57 AM, Юpa Шaлaк wrote:
>>
>> "Sergey Babkin" <sab...@hotmail.com> wrote in message

>> ...

>>> Да? А вроде ж в ODBC запросы компилируются отдельно для каждой сессии.
>>
>> При чем тут ODBC? Я говорю о том, что будет происходить на сервере.
>
> И на сервер запросы попадут как?

Так и попадут. В процессе prepare (до того, как к стейтменту будут
привязаны реальные значения).

>>> Так что если там был такой же запрос в другой сессии, оно вряд ли
>>> поможет. С другой стороны, конечно, если это какая-то веб-хрень,
>>
>> Конечно же поможет. Я же говорю об execution plan cache.
>
> Если запросы не совершенно тривиальны, у меня есть ощущение, что
> компиляция запросов гораздо быстрее их исполнения.

А на OLTP системах как раз большое количество простых запросов и создаёт
основную нагрузку.
Как-то у нас наблюдалась ситуация, когда сервер вообще непонятно чем
занимался (с загрузкой под 100%), оказалось запросы компилил. Миллионы
идентичных запросов с чуть отличающимися значениями в условиях выборки
(которые как раз надо было запихнуть в параметры). Надавали по голове
кому надо, запросы параметризовали, всё в норму пришло.

Ещё лучше статический SQL, но если уж приходится работать с
динамическим, то параметризация - правильный путь.
Исключение - когда значение параметра может существенно влиять на
оптимальность плана выполнения. Хотя и это можно обойти.

Удачи.

[Const]

Alexander Veremyev <caw...@gmail.com> wrote:
> Ещё лучше статический SQL, но если уж приходится работать с
> динамическим, то параметризация - правильный путь.

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

> Исключение - когда значение параметра может существенно влиять на
> оптимальность плана выполнения. Хотя и это можно обойти.

Как-то мне сложно себе представить, чтоб значение параметра
могло изменить execution plan.

---
Const

[Dmitry Krivitsky]

"Const" <oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...

Жизус.

[Const]

Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
видеть результаты explain plan ?

Я был бы тебе признателен, если бы ты мог нам всем тут показать,
в каком именно месте там могут появиться ветвления, связанные
с индивидуальными значениями полей.

---
Const

[Victor Alekhin]

Изменение параметра может просто все поменять

procedure do (pi_codconf in varchar2 default null,pi_progmov in number
default null ....

l_tipoTransazione :=getTipoTransazione(r.codconf,r.progmov);
CASE l_tipoTransazione
WHEN g_NC THEN
begin

setAA_AB(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
setBA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
setCA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
setCB(r.codconf,r.progmov,l_apnumber);
setCC(r.codconf,r.progmov,l_apnumber);
setCD(r.codconf,r.progmov,l_apnumber);

setDA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
setaml(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
end;
WHEN g_DI THEN -- aggiuntivo
begin

setAA_AB(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
setBA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);

setCA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione,r.maincontract);
setCD(r.codconf,r.progmov,l_apnumber);
setDA(r.codconf,r.progmov,l_apnumber,l_tipoTransazione);
end;
:
:
ELSE
logging.error('do:, tipo transazione sconosciuto '
||l_tipoTransazione,g_e);
END CASE;

[Dmitry Krivitsky]

"Const" <oc...@optonline.net> wrote in message news:j9vl1i$28v$8...@aspen.stu.neva.ru...

> Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
>> "Const" <oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...
>> > Alexander Veremyev <caw...@gmail.com> wrote:
>> >> Ещё лучше статический SQL, но если уж приходится работать с
>> >> динамическим, то параметризация - правильный путь.
>> >
>> > Мне вообще как-то непонятно, как можно иначе.
>> > То есть, конечно, понятно, что тохи-индусы, вооруженные
>> > современными фреймворками по умолчанию будут такое
>> > генерить, но на то и нужен над ними надзиратель,
>> > чтоб такое пресекать в корне.
>> >
>> >> Исключение - когда значение параметра может существенно влиять на
>> >> оптимальность плана выполнения. Хотя и это можно обойти.
>> >
>> > Как-то мне сложно себе представить, чтоб значение параметра
>> > могло изменить execution plan.
>
>> Жизус.
>
> Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
> видеть результаты explain plan ?

Да.

> Я был бы тебе признателен, если бы ты мог нам всем тут показать,
> в каком именно месте там могут появиться ветвления, связанные
> с индивидуальными значениями полей.

Ну приду на работу, сделаю copy-paste.

[Valery Lapenkov]

Const <oc...@optonline.net>:

У Веремеева речь об изменении оптимальности.

В.Лапенков.

[Sergey Babkin]

On 11/15/2011 05:52 PM, Alexander Veremyev wrote:
> On 16.11.2011 0:05, Sergey Babkin wrote:
>> On 11/15/2011 10:57 AM, Юpa Шaлaк wrote:
>>>
>>> "Sergey Babkin" <sab...@hotmail.com> wrote in message
>>> ...
>>>> Да? А вроде ж в ODBC запросы компилируются отдельно для каждой сессии.
>>>
>>> При чем тут ODBC? Я говорю о том, что будет происходить на сервере.
>>
>> И на сервер запросы попадут как?
>
> Так и попадут. В процессе prepare (до того, как к стейтменту будут
> привязаны реальные значения).

И prepare делается через что? Подсказка: если даже база данных
бежит локально на той же машине, без ODBC, что будет со всеми
этими операторами при разрывании сессии?

-СБ

[Alexander Veremyev]

On 16.11.2011 3:28, Const wrote:
> Как-то мне сложно себе представить, чтоб значение параметра
> могло изменить execution plan.

Да обыкновенный запрос по промежутку дат.
Какая-нибудь там история денежных транзакций клиента по заданным им
датам. Обычно нижняя граница - за месяц до текущей даты, но значение всё
равно приходит из клиентского приложения (пользователем вводится).

Не предполагая такого подвоха БД запросто запузырит table scan там где
не надо или скан не по тому индексу, какой бы она выбрала имея сведения
о величине запрашиваемого временного промежутка.

Способы борьбы - в одних случаях просто в непараметризованную часть
запроса включать, в других задавать в непараметризованной части
некоторые "избыточные" условия, дающие подсказки оптимизатору.
Можно, конечно, хинтами, но хинты - зло.

Удачи.

[Alexander Veremyev]

On 16.11.2011 19:28, Sergey Babkin wrote:
> On 11/15/2011 05:52 PM, Alexander Veremyev wrote:
>> On 16.11.2011 0:05, Sergey Babkin wrote:
>>> On 11/15/2011 10:57 AM, Юpa Шaлaк wrote:
>>>>
>>>> "Sergey Babkin" <sab...@hotmail.com> wrote in message
>>>> ...
>>>>> Да? А вроде ж в ODBC запросы компилируются отдельно для каждой сессии.
>>>>
>>>> При чем тут ODBC? Я говорю о том, что будет происходить на сервере.
>>>
>>> И на сервер запросы попадут как?
>>
>> Так и попадут. В процессе prepare (до того, как к стейтменту будут
>> привязаны реальные значения).
>
> И prepare делается через что?

Через call идущий в свою очередь через ODBC драйвер базы. Что там
сделает база с этим запросом (уже имея текст запроса с обозначенными
параметрами, но не имея реальных значений этих параметров) уже
исключительно её дело.
Любая взрослая СУБД положит такой запрос в уже скомпилированном виде во
внутренний кэш вместе с планом выполнения и исходным текстом запроса,
где и оставит для будущих использований (используется по по прямому
совпадению текста запроса) что для идущих параллельно, что для
последующих соединений.

> Подсказка: если даже база данных
> бежит локально на той же машине, без ODBC, что будет со всеми
> этими операторами при разрывании сессии?

Если честно, не понял.
Какая разница, локально или не локально база бежит?
Что значит "без ODBC"? Если база бежит без ODBC, то ODBC приложение к
ней не подсоединится.

Предваряя дальнейшее общение в режиме намёков и "подсказок" - если
какой-либо ODBC драйвер занимается подстановкой параметров сам, то это
либо очень частный случай (нереляционные источники и т.п.), в которых
сам драйвер выступает как псевдо-СУБД, либо очень плохая база.

Удачи.

[Sergey Babkin]

On 11/16/2011 11:13 AM, Alexander Veremyev wrote:
> On 16.11.2011 19:28, Sergey Babkin wrote:
>> On 11/15/2011 05:52 PM, Alexander Veremyev wrote:
>>> On 16.11.2011 0:05, Sergey Babkin wrote:
>>>> On 11/15/2011 10:57 AM, Юpa Шaлaк wrote:
>>>>>
>>>>> "Sergey Babkin" <sab...@hotmail.com> wrote in message
>>>>> ...
>>>>>> Да? А вроде ж в ODBC запросы компилируются отдельно для каждой
>>>>>> сессии.
>>>>>
>>>>> При чем тут ODBC? Я говорю о том, что будет происходить на сервере.
>>>>
>>>> И на сервер запросы попадут как?
>>>
>>> Так и попадут. В процессе prepare (до того, как к стейтменту будут
>>> привязаны реальные значения).
>>
>> И prepare делается через что?
>
> Через call идущий в свою очередь через ODBC драйвер базы. Что там
> сделает база с этим запросом (уже имея текст запроса с обозначенными
> параметрами, но не имея реальных значений этих параметров) уже
> исключительно её дело.
> Любая взрослая СУБД положит такой запрос в уже скомпилированном виде во
> внутренний кэш вместе с планом выполнения и исходным текстом запроса,
> где и оставит для будущих использований (используется по по прямому
> совпадению текста запроса) что для идущих параллельно, что для
> последующих соединений.

Ну, может и положить, конечно.

-СБ

[Andrey M]

Хе-хе. Генерализация подвела.

Даже без подсказанных тут case operators в современном мире есть bind
peeking. Который сильно поднасрет данной noble cause.

[Const]

Victor Alekhin <victor....@gmail.com> wrote:
> On 11/16/11 7:25 AM, Const wrote:
> > Dmitry Krivitsky<kr...@fido.fw.nu> wrote:
> >> "Const"<oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...
> >>> Alexander Veremyev<caw...@gmail.com> wrote:
> >>>> Ещё лучше статический SQL, но если уж приходится работать с
> >>>> динамическим, то параметризация - правильный путь.
> >>>
> >>> Мне вообще как-то непонятно, как можно иначе.
> >>> То есть, конечно, понятно, что тохи-индусы, вооруженные
> >>> современными фреймворками по умолчанию будут такое
> >>> генерить, но на то и нужен над ними надзиратель,
> >>> чтоб такое пресекать в корне.
> >>>
> >>>> Исключение - когда значение параметра может существенно влиять на
> >>>> оптимальность плана выполнения. Хотя и это можно обойти.
> >>>
> >>> Как-то мне сложно себе представить, чтоб значение параметра
> >>> могло изменить execution plan.
> >
> >> Жизус.
> >
> > Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
> > видеть результаты explain plan ?
> >
> > Я был бы тебе признателен, если бы ты мог нам всем тут показать,
> > в каком именно месте там могут появиться ветвления, связанные
> > с индивидуальными значениями полей.

> Изменение параметра может просто все поменять

> procedure do (pi_codconf in varchar2 default null,pi_progmov in number

Не надо нам процедур.
sql statement покажи.

---
Const

[Victor Alekhin]

On 11/16/11 8:58 PM, Const wrote:
> Victor Alekhin<victor....@gmail.com> wrote:
>> On 11/16/11 7:25 AM, Const wrote:
>>> Dmitry Krivitsky<kr...@fido.fw.nu> wrote:
>>>> "Const"<oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...

>>> Я был бы тебе признателен, если бы ты мог нам всем тут показать,
>>> в каком именно месте там могут появиться ветвления, связанные
>>> с индивидуальными значениями полей.
>
>> Изменение параметра может просто все поменять
>
>> procedure do (pi_codconf in varchar2 default null,pi_progmov in number
>
> Не надо нам процедур.
> sql statement покажи.

Все 30+ К стров в этом pkg ?

> ---
> Const

[Const]

Victor Alekhin <victor....@gmail.com> wrote:
> >> procedure do (pi_codconf in varchar2 default null,pi_progmov in number
> >
> > Не надо нам процедур.
> > sql statement покажи.

> Все 30+ К стров в этом pkg ?

Нет, один statement.

---
Const

[Victor Alekhin]

procedure что_то(pi_id in number,pi_profile in number, pi_startdt in
date, pi_enddt in date)

if pi_profile = 0 then
select что-нибудь from чего-нибудь t
where t.user_id = pi_id
and dt between pi_startdt and pi_enddt;
else
select что-нибудь from другое_чего-нибудь t
where t.user_id = pi_id
and dt between pi_startdt and pi_enddt;
end if;

В зависимости от параметров дб может исполнять совершенно
разные sql.
Даже если sql не меняется (дай мне что-то для этого
диапазона дат) дб может делать по разному для разных
дат (например может использовать локальный индекс если ты
эту самую дб правильно спроектировал).


> ---
> Const

[Dmitry Krivitsky]

"Const" <oc...@optonline.net> wrote in message news:j9vl1i$28v$8...@aspen.stu.neva.ru...

Ну вот тебе скриншоты.
База данных в Postgres.
Запрос виден в первой строке.

Эти два запроса отличаются только параметром. План разный.
http://dl.dropbox.com/u/15395488/3.jpg
http://dl.dropbox.com/u/15395488/4.jpg

Или вот тебе чего попроще.
Эти два запроса тоже отличаются только параметром. План разный.
http://dl.dropbox.com/u/15395488/1.jpg
http://dl.dropbox.com/u/15395488/2.jpg

[Dmitry Krivitsky]

"Zee" <sergiy...@gmail.com> wrote in message news:64a390c4-bf00-4616...@l24g2000yqm.googlegroups.com...

>
>> Ну вот тебе скриншоты.
>> База данных в Postgres.
>> Запрос виден в первой строке.
>>
>> Эти два запроса отличаются только параметром. План

>> разный.http://dl.dropbox.com/u/15395488/3.jpghttp://dl.dropbox.com/u/15395488/4.jpg

>>
>> Или вот тебе чего попроще.
>> Эти два запроса тоже отличаются только параметром. План
>> разный.http://dl.dropbox.com/u/15395488/1.jpghttp://dl.dropbox.com/u/15395488/2.jpg
>

> ъоъо
> он даже предоплату не попросил?

С Окраинца? Так все равно ж не даст.

> наверно партишынингг какой горизонтальный по тому нумберу?

Да.

[Const]

Да, а вот этого я и не знал.
Спасибо, интересно.


---
Const

[Dmitry Krivitsky]

"Dmitry Krivitsky" <kr...@fido.fw.nu> wrote in message news:4ec45213$0$28400$607e...@cv.net...

> "Const" <oc...@optonline.net> wrote in message news:j9vl1i$28v$8...@aspen.stu.neva.ru...
>> Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
>>> "Const" <oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...
>>> > Alexander Veremyev <caw...@gmail.com> wrote:
>>> >> Ещё лучше статический SQL, но если уж приходится работать с
>>> >> динамическим, то параметризация - правильный путь.
>>> >
>>> > Мне вообще как-то непонятно, как можно иначе.
>>> > То есть, конечно, понятно, что тохи-индусы, вооруженные
>>> > современными фреймворками по умолчанию будут такое
>>> > генерить, но на то и нужен над ними надзиратель,
>>> > чтоб такое пресекать в корне.
>>> >
>>> >> Исключение - когда значение параметра может существенно влиять на
>>> >> оптимальность плана выполнения. Хотя и это можно обойти.
>>> >
>>> > Как-то мне сложно себе представить, чтоб значение параметра
>>> > могло изменить execution plan.
>>
>>> Жизус.
>>
>> Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
>> видеть результаты explain plan ?
>>
>> Я был бы тебе признателен, если бы ты мог нам всем тут показать,
>> в каком именно месте там могут появиться ветвления, связанные
>> с индивидуальными значениями полей.
>
> Ну вот тебе скриншоты.
> База данных в Postgres.
> Запрос виден в первой строке.

Ну так что, Костя, комментарии-то будут? :-)

[Const]

Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
> >>> >
> >>> > Как-то мне сложно себе представить, чтоб значение параметра
> >>> > могло изменить execution plan.
> >>
> >>> Жизус.
> >>
> >> Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
> >> видеть результаты explain plan ?
> >>
> >> Я был бы тебе признателен, если бы ты мог нам всем тут показать,
> >> в каком именно месте там могут появиться ветвления, связанные
> >> с индивидуальными значениями полей.
> >
> > Ну вот тебе скриншоты.
> > База данных в Postgres.
> > Запрос виден в первой строке.

> Ну так что, Костя, комментарии-то будут? :-)

Я пока не рассмотрел твои картинки, мне некогда.

Всё, приводимое до сих пор, было в некотором роде
жульничеством.

---
Const

[Dmitry Krivitsky]

"Const" <oc...@optonline.net> wrote in message news:ja74sl$6ae$4...@aspen.stu.neva.ru...

> Dmitry Krivitsky <kr...@fido.fw.nu> wrote:
>> >>> >
>> >>> > Как-то мне сложно себе представить, чтоб значение параметра
>> >>> > могло изменить execution plan.
>> >>
>> >>> Жизус.
>> >>
>> >> Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
>> >> видеть результаты explain plan ?
>> >>
>> >> Я был бы тебе признателен, если бы ты мог нам всем тут показать,
>> >> в каком именно месте там могут появиться ветвления, связанные
>> >> с индивидуальными значениями полей.
>> >
>> > Ну вот тебе скриншоты.
>> > База данных в Postgres.
>> > Запрос виден в первой строке.
>
>> Ну так что, Костя, комментарии-то будут? :-)
>
> Я пока не рассмотрел твои картинки, мне некогда.

Чтобы понять то, что на картинках, достаточно двух секунд.
Ну, при условии, конечно, что ты сам-то "когда-нибудь в жизни
видел explain plain", как ты изволишь выражаться.
Zee вон все понял сразу.
Собственно, именно из-за очевидности этого use case я выше
и написал "жизус".

> Всё, приводимое до сих пор, было в некотором роде
> жульничеством.

Да? :-)
А не твое "некогда" является жульничеством?
Чтобы, как обычно, брякнув глупость и нахамив, не извиняться,
а отпираться до последнего.

[Andrey M]

On 2011/11/18 10:11 PM, Const wrote:
> Andrey M<k...@to.tam> wrote:
>> On 11/16/2011 1:25 AM, Const wrote:
>>> Dmitry Krivitsky<kr...@fido.fw.nu> wrote:
>>>> "Const"<oc...@optonline.net> wrote in message news:j9usje$alb$5...@aspen.stu.neva.ru...
>>>>> Alexander Veremyev<caw...@gmail.com> wrote:
>>>>>> Ещё лучше статический SQL, но если уж приходится работать с
>>>>>> динамическим, то параметризация - правильный путь.
>>>>>
>>>>> Мне вообще как-то непонятно, как можно иначе.
>>>>> То есть, конечно, понятно, что тохи-индусы, вооруженные
>>>>> современными фреймворками по умолчанию будут такое
>>>>> генерить, но на то и нужен над ними надзиратель,
>>>>> чтоб такое пресекать в корне.
>>>>>
>>>>>> Исключение - когда значение параметра может существенно влиять на
>>>>>> оптимальность плана выполнения. Хотя и это можно обойти.
>>>>>
>>>>> Как-то мне сложно себе представить, чтоб значение параметра
>>>>> могло изменить execution plan.
>>>
>>>> Жизус.
>>>
>>> Скажи, о Дима, тебе когда-нибудь в своей жизни доводилось
>>> видеть результаты explain plan ?
>>>
>>> Я был бы тебе признателен, если бы ты мог нам всем тут показать,

>>> в каком именно месте там могут появиться ветв ления, связанные

>>> с индивидуальными значениями полей.
>>>
>>> ---
>>> Const
>
>> Хе-хе. Генерализация подвела.
>
>> Даже без подсказанных тут case operators в современном мире есть bind
>> peeking. Который сильно поднасрет данной noble cause.
>
> Да, а вот этого я и не знал.
> Спасибо, интересно.

Понимание практических аспектов peeking на интервью отделяет людей
претендующих на extensive experience with 10g/11g performance tuning от
имеющих его.

[Victor Alekhin]

О, и много тебе приходилось интервировать людей
претендующих на extensive experience with 10g/11g performance tuning ?
Помолчим уж про понимание практических аспектов peeking.

[Andrey M]

С сентября - 30 телефонных, 10 вышли в устное. Один получил оффер и не
взял, что, впрочем, не было сюрпризом.

А что ?

[Victor Alekhin]

Не, ничего, я знаю двоих, которые понимают практические аспекты peeking
(и не только),но ни один из них не претендует на extensive experience.
Скажем так, oracle performance tuning товар весьма штучный и, как
правило, люди для него не нанимаются через интервью.

[Andrey M]

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

И да, кагбэ Джонатан Льюис или там Ричард Немец тут не нужен. Уровня
крепкого Oracle ACS вполне хватит - они нормально в пикинге шарят. :-)
А таких в стране тыща-другая и в данной metropolitan area под сотнб
будет. Но все хорошо сидят. :-)

[Victor Alekhin]

>>>> О, и много тебе приходилось интервировать людей
>>>> претендующих на extensive experience with 10g/11g performance tuning ?
>>>> Помолчим уж про понимание практических аспектов peeking.
>>>
>>> С сентября - 30 телефонных, 10 вышли в устное. Один получил оффер и не
>>> взял, что, впрочем, не было сюрпризом.
>>>
>>> А что ?
>>
>> Не, ничего, я знаю двоих, которые понимают практические аспекты peeking
>> (и не только),но ни один из них не претендует на extensive experience.
>> Скажем так, oracle performance tuning товар весьма штучный и, как
>> правило, люди для него не нанимаются через интервью.
>
> Ну тут смотря какой тюнинг. Наши задачи как правило не "чтоб всё
> летало", а "чтоб вот это начало работать пусть два часа, но
> гарантированно. А не сегодня минуту а завтра - день". Просто в контексте
> не самых хороших времен у начальства была надежда что кто-нибудь
> приличный оказался вымыт на панель и залетит в бредень.
>
> И да, кагбэ Джонатан Льюис или там Ричард Немец тут не нужен. Уровня
> крепкого Oracle ACS вполне хватит - они нормально в пикинге шарят. :-) А
> таких в стране тыща-другая и в данной metropolitan area под сотнб будет.
> Но все хорошо сидят. :-)
>
>
>

Как я тебя понимаю :-)