Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет mumuntu ([info]mumuntu)
@ 2011-07-20 04:36:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Я тут был на собеседовании (регулярно хожу, чаще, чем к врачу, это не значит, что я хочу работу сменить), и меня один коллега-джавадевелопер попросил решить известную задачу про две таблицы со связью между ними и все значения из первой таблицы, которые не имеют связи во второй таблице.
Когда я ему ответил, что надо сделать LEFT JOIN с WHERE <fk второй таблицы> IS NULL, он мне заявил, что это неоптимально, и предложил вариант с NOT EXISTS.

Дорогие коллеги-джавадевелоперы!
Если в вашей голове запрос с NOT EXISTS в плане выглядит оптимальнее, чем запрос с LEFT JOIN, крайне рекомендую синхронизировать ваше внутреннее представление с реальным планом запроса базы.
А еще лучше - не беритесь рассуждать о том, в чем не разбираетесь.
Что интересно, коллега мне еще сказал, что в случае с NOT EXISTS не нужен подзапрос (?). Я не знаю, как это трактовать, совсем вы офигели в своей джаве.

Upd.: в комментариях и в связанной записи коллеги [info]plumqqz@lj произошло интересное обсуждение, по результатам которого я пошел и нашел блогозапись коллеги Quassnoi, в которой изложена вся информация по теме LEFT JOIN vs NOT EXISTS применительно к MySQL.


(Добавить комментарий)


[info]alexclear@lj
2011-07-19 20:38 (ссылка)
Вообще, чего только не услышишь на собеседованиях.
Еще один коллега мне не поверил, что MyISAM в современном мире не производительнее InnoDB.

(Ответить) (Ветвь дискуссии)


[info]ext_663183@lj
2011-07-19 20:54 (ссылка)
Джавист ныне хуже похапешника, факт.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kurilka@lj
2011-07-20 02:16 (ссылка)
а денег хочет раза в 1,5 больше

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yantayga@lj
2011-07-21 16:08 (ссылка)
Кстати, я вот удивился зарплатам джавистам... Они просто делают всех, кроме ABAP!

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kurilka@lj
2011-07-21 16:10 (ссылка)
А я и на ABAP/4 попоисать успел, хотя там предметка (точней знание продуктов) ценится, да и сертификат по жабе от SAP был энное число лет назад :)

(Ответить) (Уровень выше)


[info]nivanych@lj
2011-07-20 02:28 (ссылка)
На небольших объёмах и простых операциях быстрее.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kun99@lj
2011-07-20 02:50 (ссылка)
Там где пара транзакций в секунду по праймари вытянуть один ряд? Возможно. В остальных случаях тот же Percona порвет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nivanych@lj
2011-07-20 02:56 (ссылка)
Да и вообще говоря, сравнивать их некорректно.
Percona да. Сделали лучший NoSQL, пожалуй.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sa_chernomor@lj
2011-07-20 03:10 (ссылка)
HandlerSocket? Его вроде не они сделали, только интегрировали в свою сборку.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nivanych@lj
2011-07-20 03:13 (ссылка)
Готовое не только из HandlerSocket состоит.
Они таки немало сделали.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sa_chernomor@lj
2011-07-20 03:18 (ссылка)
А что именно? Я не очень в теме - в своем блоге они на эту тему особо много не писали, а за изменениями в percona server не слишком внимательно слежу.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nivanych@lj
2011-07-20 03:28 (ссылка)
Ну, XtraDB. Всё-таки, они там немало доработали.
Если честно, я тоже не очень внимательно слежу.
Нахожу, что полагаться на NoSQL, зачастую, это халтура ;-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sa_chernomor@lj
2011-07-20 04:07 (ссылка)
Ну XtraDB довольно косвенно относится к NoSQL.. :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nivanych@lj
2011-07-20 04:12 (ссылка)
Довольно прямо относится. Так же, как и InnoDB.
Из-за его специфики, на нём вполне можно создавать производительные NoSQL-решения, в отличие, скажем, от постгреса.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sa_chernomor@lj
2011-07-20 04:15 (ссылка)
А в чем отличие от постгреса?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nivanych@lj
2011-07-20 04:38 (ссылка)
InnoDB каждой таблицы имеет кластерный индекс по PK.
Если PK в таблице нет, то он его создаёт сам и таки имеет по нему кластерный индекс.
В оракловой терминологии это называется индекс-организованной таблицей (index-organized).
Его реализация, обычно, представляет собой помещение данных в структуру индексного дерева.
Это позволяет ускорить точечные запросы, и особенно сильно, запросы по диапазонам ключей.
Но замедляет работу, упрощённо говоря (есть нюансы), при запросах по нескольким индексам.

В постгресе же таблица хранится отдельно от индексов, в "плоском" виде.
Но есть возможность отсортировать таблицу физически по любому набору колонок.
После такой сортировки, производительность запросов по диапазонам индексов резко возрастает.
Но "на ходу" оно такое делать не умеет.
Можно извращаться с индексами по выражениям над составными полями (поле состоит много, из чего, но сравнивается только по одному какому-то элементу), но по моему мнению, это ближе к извращению, чем к нормальной работе. Да и планы запросов надо будет смотреть очень внимательно, чтобы был всё время, где нужно, index only scan. Да и при записи, всё равно, будет засовывать в плоскую табличку. Я так не делал, только предполагаю, что можно так извратиться.
Вроде бы, в 9.2 обещаются с этим что-то хорошее сделать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sa_chernomor@lj
2011-07-20 04:52 (ссылка)
понятно, спасибо

(Ответить) (Уровень выше)


[info]yakovis@lj
2011-07-19 21:09 (ссылка)
должно быть «и это не значит, что я такой здоровый»

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-19 21:10 (ссылка)
^ Важное дополнение! :)

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-19 22:04 (ссылка)
Еще мне один коллега сказал, что thread dump в Java это дорогая операция.
Вообще, мне кажется довольно нелепым спорить с людьми, которые, вроде как, меня интервьюируют, я обычно и не спорю.
Ну, дорогая так дорогая. А в NOT EXISTS нет подзапроса. И MyISAM производительнее InnoDB.
Понабирали блин хрен знает кого, скоро уже мышам аутсорсить начнут.
А, еще один боец не поверил, что на NIO можно сделать обращение к веб-сервису. И ведь это Java team lead вроде бы серьезного проекта, а не PHP-кодер.

(Ответить) (Ветвь дискуссии)


[info]juliy@lj
2011-07-19 22:10 (ссылка)
http://prostopleer.com/tracks/3991591VMqT

(Ответить) (Уровень выше)


[info]dph@lj
2011-07-20 05:28 (ссылка)
Честно говоря, team lead большого java проекта, которому нужно тебя собеседовать (и он про тебя никогда не слышал) - это уже довольно странно (

(Ответить) (Уровень выше)


[info]bmikle@lj
2011-07-19 23:23 (ссылка)
Хи-хи

(Ответить)


[info]juan_gandhi@lj
2011-07-20 01:00 (ссылка)
Блаженъ мужъ iже не иде на советъ нечестивыхъ (яти по вкусу)

(Ответить) (Ветвь дискуссии)

И без ятей хорошо получилось
[info]plumqqz@lj
2011-07-20 06:47 (ссылка)
Не "iже", а "иже".

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: И без ятей хорошо получилось
[info]fkng_stupid_lj@lj
2011-07-20 16:49 (ссылка)
Но одинъ ять всё-таки нуженъ — в словѣ «совѣтъ» :)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: И без ятей хорошо получилось
[info]plumqqz@lj
2011-07-20 17:02 (ссылка)
Про яти было сказано - "по вкусу". По вкусу так по вкусу.

(Ответить) (Уровень выше)

Re: И без ятей хорошо получилось
[info]juan_gandhi@lj
2011-07-21 03:02 (ссылка)
Ой. Спасибо. Которыиже. Стормозил.

(Ответить) (Уровень выше)


[info]satanail@lj
2011-07-20 01:04 (ссылка)
настоящие программисты манов не читают

(Ответить)


[info]alexshubert@lj
2011-07-20 03:29 (ссылка)
Парень, заваливший меня на собеседовании в mail.ru, сообщил, что CAS-операции в sun.misc.unsafe "ломаются" при превышения некоторого количества асинхронных операций. И что проблема даже не в них, а в самой архитектуре процессора, то есть, ломается сама архитектура многоядерных процессоров. Код или пример привести отказался.

(Ответить) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 05:00 (ссылка)
Может он про это: http://en.wikipedia.org/wiki/Memory_ordering

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 06:02 (ссылка)
Либо я не понимаю сути, либо CAS операции гарантируют выполнение проверил-установил. А в статье речь о том, что что могут быть перемешаны операции, в угоду оптимального использования кэша, если они не затрагивают барьеры. СAS, конечно, не барьер, но если бы он "ломался" под нагрузкой, то, по-моему, это бы означало конец мультипоточной разработки в целом. я ошибаюсь?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 07:15 (ссылка)
Да, просто CAS работает на x86. На других платформах должен быть memory barrier, потому что cas гарантирует ордеринг обращений к одному слову памяти. Но что может происходить в соседних кэш-лайнах — не гарантируется.

Пример.

У тебя есть какая-то структура, которая висит за поинтером, который защищён CAS. Локфри. Ты идёшь туда по поинтеру, читаешь структуру, делаешь её копию, изменяешь какие нужно тебе поля. Затем поинтер меняешь через CAS, замещая старую структуру новой.

Казалось бы, всё ок — у тебя произошла атомарная операция записи, и все кто пришёл после неё видят новую структуру.

Но на самом деле на некоторых процессорах (Alpha) может произойти такая шняга: другие ядра увидят операцию CAS и смену поинтеров раньше, чем заполнение новой структуры. В итоге они пойдут, прочитают поинтер (новый), но будут работать со структурой, в которой часть полей не до конца заполнены.

И естественно, на однопроцессоре это будет создавать видимость работоспособности, и при небольшой (или неоптимальной) загрузке во многопроцессорной конфигурации будет создавать видимость работоспособности. Но на самом деле одного CAS в общем случае недостаточно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 07:22 (ссылка)
Последний абзац применим к x86?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 07:49 (ссылка)
Неа.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 07:51 (ссылка)
Спасибо за пояснения.

(Ответить) (Уровень выше)


[info]ext_563095@lj
2011-07-20 08:52 (ссылка)
CAS в смысле memory ordering эквивалентен fence instructions, тут вы правы. Если "ломается архитектура многоядерных процессоров", это значит что-то не так в c memory coherence protocol (MESI (http://en.wikipedia.org/wiki/MESI_protocol)). Впервый раз про это слышу - жалко что этот парень не выдал каких-нибудь ссылок на почитать...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_563095@lj
2011-07-20 09:00 (ссылка)
Вот еще ссылочка, в том числе затрагивающая тему CAS на MPS: http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
Под CAS (на x86) они имеют ввиду LOCK:CMPXCHG.

(Ответить) (Уровень выше)


[info]dair_spb@lj
2011-07-20 04:08 (ссылка)
Я не спец ни в Java, ни в базах данных, но мне почему-то кажется (уже крещусь), что left join выиграет на небольшом наборе данных, а not exists — на большом.

Надо бы проверить, чо.

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 04:26 (ссылка)
Планы полностью одинаковые, один к одному, я смотрел на небольшом наборе данных, правда.
LEFT JOIN может быть эффективнее, поскольку у него есть шансы использовать индекс, а у запроса с NOT EXISTS таких шансов нет, так как это всегда фуллскан.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]webbyte@lj
2011-07-20 06:41 (ссылка)
Пиздеж.
У меня под рукой только Оракел и Мускул, но оба юзают индекс в случае запроса с not exists.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 06:45 (ссылка)
А можно план глянуть?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]zamotivator@lj
2011-07-20 18:26 (ссылка)
Не ебу планы, но потверждаю - в нормальном оптимизаторе Not Exists будет преобразован в AntiSemiJoin, что фактически эквивалентен обычному джойну.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 18:27 (ссылка)
В MySQL все что угодно преобразуется в фактический эквивалент обычного джойна

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]zamotivator@lj
2011-07-20 18:28 (ссылка)
Нет, не всё - попробуй квантифицированные сравнения на lt, gt, ne

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-20 06:45 (ссылка)
Я к тому, что используют индекс, конечно.
По второй таблице, которая в подзапросе.
А по первой - скан.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_398200@lj
2011-07-20 07:01 (ссылка)
А вот фигушки :)

select t1.id from t1
WHERE not exists (select 1 from t2 Where t1.Id = t2.id)

SELECT STATEMENT, GOAL = ALL_ROWS
HASH JOIN ANTI
INDEX FAST FULL SCAN MPMREAL1 PT1
TABLE ACCESS FULL MPMREAL1 T2


select t1.Id from t1 left join t2 on (t1.Id = t2.Id)
where t2.Id is null

SELECT STATEMENT, GOAL = ALL_ROWS
HASH JOIN ANTI
INDEX FAST FULL SCAN MPMREAL1 PT1
TABLE ACCESS FULL MPMREAL1 T2

t1 - (999 rows) (pk pt1)
t2 - (1999999 rows) (pk pt2)


(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 07:03 (ссылка)
Да собственно вот: http://explainextended.com/2009/09/18/not-in-vs-not-exists-vs-left-join-is-null-mysql/
Там все есть, я нашел уже.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_224331@lj
2011-07-20 07:34 (ссылка)
В MySQL LEFT JOIN немного (немного) эффективнее, чем NOT EXISTS из-за небольших различий в реализации JOIN и DEPENDENT SUBQUERY. Планы по сути одинаковые.

В SQL Server для неуникальных полей LEFT JOIN менее эффективен, чем NOT EXISTS.

В PostgreSQL и Oracle планы и алгоритмы полностью идентичны.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 07:46 (ссылка)
Ага, спасибо!

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-20 07:18 (ссылка)
^ поправка, скан будет не всей таблицы, а индекса.
Но в целом, для мускуля что LEFT JOIN, что NOT EXISTS - сила ночи, сила дня, чего еще вы ожидаете от сервера, который умеет только nested loops?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_224331@lj
2011-07-20 07:51 (ссылка)
В обоих случаях (и LEFT JOIN, и NOT EXISTS) левая (внешняя) таблица будет ведущей, а правая (внутренняя) — ведомой в цикле.

Будет ли по ней fullscan или нет, зависит от других условий запроса: если в условии WHERE есть фильтр по индексированному полю ведущей таблицы с высокой кардинальностью, то будет index range или index ref по этому полю в ведущей таблице.

Проблема MySQL не в том, что обязательно будет fullscan, а в том, что невозможно изменить порядок исполнения циклов. Впрочем, для anti-join по индексированному полю это особой роли и не играет.

(Ответить) (Уровень выше)


[info]qserge@lj
2011-07-20 05:34 (ссылка)
Мне тут на собеседовании доказывали, что критическая секция хороша тем, что поток, вошедший в неё тормозит все(sic!) остальные потоки в процессе, даже те, которые про секцию ничего не знают.

(Ответить) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 06:36 (ссылка)
Его ждет потрясение, когда он откроет для себя неблокирующие алгоритмы...

(Ответить) (Уровень выше)

Борьба невежества с некомпетентностью
[info]pingback_bot@lj
2011-07-20 06:33 (ссылка)
User [info]plumqqz@lj referenced to your post from Борьба невежества с некомпетентностью saying: [...] Все, все красавцы [...]

(Ответить)


(Анонимно)
2011-07-20 08:22 (ссылка)
повторю:
php сосёт, mysql сосёт

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 08:29 (ссылка)
Что сосет, я и сам прекрасно знаю, интереснее было бы послушать о том, а что не сосет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 08:31 (ссылка)
Но, прежде чем начинать этот высокоинтеллектуальный разговор, надо будет учесть, что я старый пионер, и видел в жизни многое.
Так вот, сосет всё.

(Ответить) (Уровень выше)


[info]jdevelop@lj
2011-07-20 14:27 (ссылка)
в люксе для банков оракл, чего ты к ним про mysql?

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-20 14:37 (ссылка)
Тут в комментариях коллега пишет, что для оракла планы будут полностью эквивалентны.
Я-то к ним с MySQL, потому что я для оракла запросы лет 10 назад тюнил.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-20 14:38 (ссылка)
я в планы не смотрел, но не вижу какой такой магией not exists может быть быстрее чем left join

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]plumqqz@lj
2011-07-20 17:12 (ссылка)
Конечно, может:
http://www.databasejournal.com/features/oracle/article.php/3706506/Hashing-in-Oracle.htm

Конечно, не в мыскле.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 03:10 (ссылка)
оке, буду знать

(Ответить) (Уровень выше)


[info]zamotivator@lj
2011-07-20 18:32 (ссылка)
NOT EXISTS может быть преобразован в AntiSemiJoin - что, по сути, эквивалент LEFT JOIN ... ON left.key = right.key OR right.key IS NULL.
Алгоритмически они реализуются одинаково - nested loops, hash, merge, index-lookup.
LEFT JOIN требуется выдавать на выходе записи, которые есть и слева и справа, а потом уже дополнительно их дофильтровывать additional condition (right.value IS NULL).
Таким образом, NOT EXISTS будет быстрее (при условии, что оптимизатор корректно его оптимизирует).

В идеале оптимизатор должен все такие варианты сводить в AntiSemiJoin и не ебать мозги

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 03:10 (ссылка)
значит в люксе все правильно сказали

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 03:20 (ссылка)
Так жить нельзя.
Даже в рамках этого обсуждения одни говорят одно, другие - другое, вот, например:
http://alexclear.livejournal.com/481080.html?thread=9675832#t9675832

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 03:37 (ссылка)
ты мне другое скажи - НАХУЯ жабадевелоперу знать все эти оптимизадницы разных SQL? разве это не дело DBA?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 03:47 (ссылка)
А нахуя жабадевелоперу знать, как внутри устроен хэшмэп в Java или там Hibernate, если он не будет их сам переписывать?
Так мы дойдем до того, что и таблицу умножения знать не надо, калькулятор посчитает.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 12:52 (ссылка)
так, я проведу аналогию - в жабе досконально надо знать все, ну или стремиться к этому

если интервью как жабадевелопера - то собственно жаба, потоки, коллекции там всяекие, фреймворки, юнит-тесты и прочее говно

дазы банных - это уже сбоку

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 14:07 (ссылка)
Ну включи фантазию, нельзя всю жизнь думать как человек из сервисной лавки.
Хотя, конечно, если ты все время хочешь разрабатывать по заказу дяди из Штатов, тогда да, ты должен знать:

собственно жабу, потоки, коллекции там всяекие, фреймворки, юнит-тесты и прочее говно

А на самом-то деле:

собственно жаба

Это язык, придуманный от безысходности для тех, кто вчера овец пас, а сегодня хочет писать код.
На Java до сих пор не написано ни одного браузера общего назначения. Почему? Потому что тем, кто могут написать браузер, Java как язык не очень нужна.

потоки

Люди, которые уже научились синхронизировать два потока, почему-то чувствуют себя офигенно гордыми, хотя, очевидно, разделение проходит не здесь. Для обычного человека потоки слишком сложны, а для профессионала вопрос не в потоках, см. Erlang или ту же Akka (я, кстати, не уверен, что л-софтовцы в массе вообще слышали про Akka).

коллекции там всяекие

Смотри, 8 лет назад на собеседованиях у джава-девелоперов спрашивали все то же - потоки, собственно жабу, коллекции. Ничего не поменялось. За это время многоядерные процессоры стали мейнстримом, появились SSD-накопители и памяти в коробках стало столько, сколько мы раньше и представить себе не могли. А коллекции все те же, сюрприз! И все так же спрашивают, а как вы будете синхронизировать доступ к коллекции? Ладно, хотя бы ReadWriteLock появился, и то хлеб.

фреймворки

В Java фреймворки решают задачу построения стектрейсов из XML-конфигов, при этом, если раньше они плодились как грибы, то сейчас они более-менее равномерным слоем размазаны по поверхности. Что сейчас изучать? Spring Framework? Но это же говно, есть PicoContainer. И так далее.

юнит-тесты

Ага, а еще JMS, ESB, OSB и USB.
Мне интересно, а что можно знать или не знать в юнит-тестах или JMS?
Эти вещи предполагают какие-нибудь действительно сложные шаблоны использования?
Вот если бы при использовании юнит-тестов были бы возможны race conditions, что называется, by design, это было бы дело, да, приходилось бы следить за своей задницей.
А сейчас что?

и прочее говно

Именно, прочее говно.

дазы банных - это уже сбоку

Прикинь, Java - это всего лишь посредственный интерфейс между пользователем и базой данных, а также средство для создания рабочих мест на всех уровнях.
И крайне редко Java это действительно инструмент создания приложений, но в этом случае (сюрприз!) ты кроме коллекций-JMS-юниттестов должен знать Eclipse RCP и другие сопутствующие товары.
Если у тебя есть база и ты пишешь под веб, на кой хрен тебе коллекции? Тебе нужен off-heap cache, чтобы коллектор с ума не сходил на больших нагрузках и чтобы не думать про "утечки памяти" (еще один отличный вопрос, какая память может утекать в веб-приложении? если какая-то утекает, то его просто писали криворукие разработчики). В 2011 году если ты пишешь под веб, тебе даже MVC фреймворк на сервере не нужен, так как у тебя rich browser application, AJAX и т.п., тут вообще можно сервер делать на голых сервлетах. Зачем потоки? Чтобы затрахаться? PHP-сты пишут безо всяких потоков годами.
Единственное, что тебе по-настоящему нужно, это база и кэш. И если ты напишешь мега-приложение на Java и обосрешься на уровне базы, работать ничего не будет, я тебе клянусь. Даже если ты возьмешь брендовое железо для сервера приложений и вкатишь на него веблоджик или что там сейчас модно.
И тут все такие проснулись - "а мы наймем DBA!"
Естественно, вы наймете DBA, куда ж вы денетесь. Просто непонятно, зачем вы всех остальных нанимали. Чтобы делать из рекордсетов джавовские объекты? Напрасный труд, кастомеру не джавовские объекты нужны, а визуальное представление информации на экране монитора.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 14:12 (ссылка)
ниасилил, многабуков

у тебя все хорошо?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 14:14 (ссылка)
Не, ну а для кого я все это писал?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 15:49 (ссылка)
ну, я таких высеров видел очень и очень много, даже и комментировать неохота, ибо много чего таки правда

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

пичаль короч

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yantayga@lj
2011-07-21 16:02 (ссылка)
Ну так человеки ж!

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-21 14:20 (ссылка)
Это была феерическая расстановка точек над джава, если что.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tretiy3@lj
2011-07-21 14:27 (ссылка)
да и не только над джава, на самом деле.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dimatorm@lj
2011-07-21 16:00 (ссылка)
попался тебе дебил уоторый наверно не знал что такое LEFT JOIN
и вот ты аппроксимируешь свой говноэкспириенс на весь мир.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 16:04 (ссылка)
ТЫ КТООООА?

(Ответить) (Уровень выше)


[info]jdevelop@lj
2011-07-21 15:47 (ссылка)
Алекс, не нада мне доказывать что жаба говно, я это и сам кому хошь могу рассказать

(Ответить) (Уровень выше)


[info]rssh@lj
2011-07-21 14:40 (ссылка)
Все фигня, кроме пчел.
Хотя, если подумать: пчелы тоже фигня. Их много и они жужжат.

(Ответить) (Уровень выше)


[info]metaclass@lj
2011-07-21 14:59 (ссылка)
Ужасно, я считал, что так думают только программисты на хаскеле, которые жабьи фреймворки и сервера приложений осилить не смогли по причине того, что смотрят на доки, а видят индию и индусов.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 15:02 (ссылка)
Но что конкретно они не смогли осилить, и что там вообще нужно осиливать?
Ведь не рокет саенс, вроде.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]metaclass@lj
2011-07-21 15:09 (ссылка)
У меня лично в мозг не влазит. Хотя это может быть, что я пытаюсь это дело привычным образом, с наскока осилить.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 15:50 (ссылка)
там как правило моск не надо, надо рефлексы

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yantayga@lj
2011-07-21 16:04 (ссылка)
чтоб чуть что - сразу - бдыщь!

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 16:20 (ссылка)
ну да, такой себе конечный автомат

надо например чота в базу совать - хуякс, JPA/Hibernate!!!!!11111пыщь

и думать не надо, какой нахуй SQL и оптимизадница. мы тут в хибернейте кэш второго уровня - и не ебет никого ничего

тьфу

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yantayga@lj
2011-07-21 16:25 (ссылка)
Да ладно, не кипятись, пойди отвлекись (http://projecteuler.net)

(Ответить) (Уровень выше)


[info]udpn@lj
2011-07-22 15:00 (ссылка)
ага, увидел джавадоки и сразу В ЕБЛИЩЕ

(Ответить) (Уровень выше)


[info]plumqqz@lj
2011-07-21 17:31 (ссылка)
Смирения у Вас не хватает.

(Ответить) (Уровень выше)


[info]_slw@lj
2011-07-21 15:06 (ссылка)
они мечтают о гоа, нет бабла нах?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]plumqqz@lj
2011-07-21 17:33 (ссылка)
о гоа бабла.
Или даже так:
О, Гоа Бабла!

(Ответить) (Уровень выше)


[info]raydac@lj
2011-07-21 16:04 (ссылка)
все компьютерные языки - зло.. лично я за программирование, а не за языки программирования

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dmzlj@lj
2011-07-21 16:10 (ссылка)
Программировать должны рабы, а думать --- философ.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]raydac@lj
2011-07-21 16:11 (ссылка)
рабы должны кодить

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-21 16:12 (ссылка)
Так ведь сейчас так и есть - рабы программируют, только вот никто не думает при этом.

(Ответить) (Уровень выше)


[info]bopm@lj
2011-07-21 16:09 (ссылка)
Почему я знал кому ты пишешь еще на втором абзаце, хотя открылся тред с этого коммента?

(Ответить) (Уровень выше)


[info]dph@lj
2011-07-21 19:49 (ссылка)
Хм. Так на чем лучше писать middleware? Впрочем, на чем писать фронты - вопрос столь же занятный :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 19:51 (ссылка)
Можно писать и на Java, это совершенно нормально.
Главное не тянуть в проект лишнего.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dph@lj
2011-07-21 19:57 (ссылка)
Ну, я лишним, вроде бы, почти не страдаю.
Кстати, про фронты - это вполне сереьзный вопрос - на чем сейчас лучше делать фронт? Ту фигню, что собирает данные с кучки сервисов (в json, например), чуть-чуть причесывает и отдает пользователю. Нормальный веб-портал, не корпоративка, не RIA.

Бэки-то, наверно, лучше на java так и делать - это мне просто проще :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 19:58 (ссылка)
Так может прямо на клиенте и собирать?
Прямо джаваскриптом?
Сейчас это модно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dph@lj
2011-07-21 20:08 (ссылка)
А черт его знает. Я такую подход, если помнишь, еще лет пять назад проповедовал - но сейчас мне это как-то не нравится. Для RIA что-нибудь вроде GWT - замечательно. А вот для нормального приличного сайта, для которого нужно думать о SEO, например - как-то не то...

Думал о чем-нибудь вроде XScript, но с человеческим лицом (типа того, что в hh сделали) - но тут опять проблема специальных верстальщиков и прочие проблемы. Я вот уже всерьез подумываю, что php - хороший выбор, хотя бы программистов куча :)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]gabaidulin@lj
2011-07-22 17:53 (ссылка)
А что в hh сделали?

(Ответить) (Уровень выше)


(Анонимно)
2011-07-21 21:12 (ссылка)
ржу
какие ещё точки над жабой

1) JTA и этим все сказано, хуярьте ролбэки или коммиты руками в зависимости от контекста в своём сраном пэхопе.

2) dependency injection самописный в пхп? ололо да и только

3) распределённые трансакции в пхп? лолват?
я же пхпшник, говорите помедленнее!

4) application server? а что это, я все через базу делаю или через мемкэш!

5) IDE? да я в консоли набыдлокодю так что хуй кто прочитает, нахуй мне IDE.

я бы продолжал и продолжал, но мне лень. плюю на тебя дорогой слюной энтерпрайзера из европы, с высот jboss, oracle и многих тысяч евро в месяц.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-21 21:56 (ссылка)
КАКОЙ PHP ПОЧЕМУ PHP ТЫ ЧТО ДУРАК БЛЯДЬ?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]udpn@lj
2011-07-22 15:08 (ссылка)
Блин, так смешно, когда какой-то неадекват приходит в тред, и совершенно адекватный до этого момента alexclear так ХУЯК КАПСОМ ДЖАСТИФАЙ РАСПИДОРАСИЛО

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 15:10 (ссылка)
Так ведь годы тренировки-то
Зря, что ли, добру пропадать

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-21 22:10 (ссылка)
1) JTA и этим все сказано

JTA - это что-то вроде USB, да?

2) dependency injection самописный в пхп? ололо да и только

Он и в джаве не был нужен, прикинь, да?
Работодателям только не говори, а то прозреют еще и нахуй пошлют.
Напридумывали поебени, DI, IoC, "когда коту нечем заняться - он лижет яйца".

3) распределённые трансакции в пхп? лолват?
я же пхпшник, говорите помедленнее!


Попробуй найти в современном мире СУБД без поддержки 2PC.
При чем тут PHP?

4) application server? а что это, я все через базу делаю или через мемкэш!

Что такое application server, по-твоему?
Apache+mod_php не подойдет?

5) IDE? да я в консоли набыдлокодю так что хуй кто прочитает, нахуй мне IDE.

Хули ты здесь матом ругаешься, быдлота ебаная?
Мне нахуй IDE не впал, например.

я бы продолжал и продолжал, но мне лень.

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

плюю на тебя дорогой слюной энтерпрайзера из европы, с высот jboss, oracle и многих тысяч евро в месяц.

Носки не обмочи, энтерпрайзер.
Привет Европе, не проебите там ее закат.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]doutorcv@lj
2011-07-22 05:38 (ссылка)
это вот сейчас очень круто было.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 06:36 (ссылка)
да, крутая истерика

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]doutorcv@lj
2011-07-22 10:02 (ссылка)
ты кто

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 13:41 (ссылка)
задувает свечку
кто здесь?!

(Ответить) (Уровень выше) (Ветвь дискуссии)

и сквозь темноту пробивается
[info]udpn@lj
2011-07-22 15:10 (ссылка)
э, пацан!

(Ответить) (Уровень выше)

Re: Ответ на ваш комментарий...
[info]doutorcv@lj
2011-07-25 16:49 (ссылка)
а, так ты дурак.

(Ответить) (Уровень выше)

Объективности ради
[info]plumqqz@lj
2011-07-22 08:11 (ссылка)
JTA - это что-то вроде USB, да?

Нет, это самое симпатичное в жабе.

Попробуй найти в современном мире СУБД без поддержки 2PC.

Для 2PC кроме менеджера данных нужен еще и менеджер транзакций, роль которого и выполняет аппсервер. Собственно, можно жить в оракловом мире - там роль менеджера выполняет сама база, но это достаточно замкнутый мир. Кроме того, 2PC должны поддерживать не только базы, но JMS-провайдеры; хотя часто они оказываются внутри СУБД.

Что такое application server, по-твоему?
Apache+mod_php не подойдет?


Так что извольте видеть - не подойдет.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Объективности ради
[info]alexclear@lj
2011-07-22 08:29 (ссылка)
Нет, это самое симпатичное в жабе.

Акронимы? =)

Для 2PC кроме менеджера данных нужен еще и менеджер транзакций, роль которого и выполняет аппсервер.

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

Так что извольте видеть - не подойдет.

На роль транзакшн менеджера - ну да, наверное, не подойдет.
На роль аппсервера - так он и есть аппсервер.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Объективности ради
[info]plumqqz@lj
2011-07-22 08:41 (ссылка)
Это называется транзакшн менеджер или дистрибьютед транзакшн координейтор.

Вот его роль и играет аппсервер. В смысле одна из подсистем. Остальные, действительно, нахер не нужны.

(Ответить) (Уровень выше)

Re: Объективности ради
[info]alexclear@lj
2011-07-22 08:34 (ссылка)
Ваш комментарий, кстати, еще одно отличное доказательство того, что различного рода "джейбоссы" и прочие мерзости джавы не нужны ровно до тех пор, пока не нужны эти самые распределенные транзакции.
Кстати, они и после этого не нужны, что мешает JTA использовать прямо из сервлет контейнера.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: Объективности ради
[info]plumqqz@lj
2011-07-22 08:47 (ссылка)
Ваш комментарий, кстати, еще одно отличное доказательство того, что различного рода "джейбоссы" и прочие мерзости джавы не нужны ровно до тех пор, пока не нужны эти самые распределенные транзакции.

Абсолютно согласен; поэтому на комментарии типа "мы используем только сервлеты и jpa" хочется спросить "вы такие мудаки потому что родились или кто-то потом сделал?"

Кстати, они и после этого не нужны, что мешает JTA использовать прямо из сервлет контейнера.

Ну, не знаю - обычно это все еще замешано на вебсервисы и ejb, и придется в итоге собирать в итоге свой аппсервер.

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

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

(Ответить) (Уровень выше)


[info]bak1an@lj
2011-07-22 06:47 (ссылка)
>На Java до сих пор не написано ни одного браузера общего назначения. Почему? Потому что тем, кто могут написать браузер, Java как язык не очень нужна.
Image

(Ответить) (Уровень выше)


[info]alexshubert@lj
2011-07-22 07:04 (ссылка)
Про овцепасов - это ты хорошо, сильно задвинул.

На java, и правда, нет браузеров. Если вдуматься, как и новых браузеров.
Опера, ИЕ, Мозилла, Сафари - поделки древних лет с переплетенной историей кода. Нет необходимости. Вот в СУБД необходимость была и написано их много. В том числе, на Java

Ох, уже 2 дня. Пойду, пора овец выгонять.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 07:10 (ссылка)
На самом-то деле, на Java есть браузеры, просто народ о них не знает.
Но они есть, причем, появились тоже довольно давно. Это коммерческие продукты, как я помню.
Кроме Оперы, etc. есть еще Chrome и куча разных браузеров на WebKit, да и сам WebKit, в общем-то, не такая уж древняя поделка, сколько ему там, лет пять? Была бы необходимость перейти на Java, как на инструмент написания браузеров - невидимая рука рынка отрегулировала бы, перешли бы. Но необходимости пока не было.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-22 07:15 (ссылка)
Apple's WebKit ты имеешь в виду? Саша, но ему уже 9 своих и 13 полных лет и он, как утверждают злые языки, впитал то ли наработки нетскейпа, то ли кого-то из авторов.

Переходить была необходимость у оракла, который свои разработки перевел на Java задолго до покупки Sun.

Саша, у тебя все в порядке?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 07:23 (ссылка)
Apple's WebKit ты имеешь в виду? Саша, но ему уже 9 своих и 13 полных лет и он, как утверждают злые языки, впитал то ли наработки нетскейпа, то ли кого-то из авторов.

WebKit это рефакторинг конкверора, вернее, KHTML.
Вон, я смотрю, уже какой-то WebKit2 анонсировали, но на Java при этом все равно пока не переходят.

Переходить была необходимость у оракла, который свои разработки перевел на Java задолго до покупки Sun.

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

Саша, у тебя все в порядке?

Очевидно же, нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-22 07:39 (ссылка)
Это не отменяет факт его почтенного возраста.

Вон, я смотрю, уже какой-то WebKit2 анонсировали, но на Java при этом все равно пока не переходят.
Разумеется, ведь они готовят его на основе старого кода.

ри этом оракл никогда не делал браузеры общего назначения
Он еще и орехоколок не делал. Что за аргумент такое, причем тут вообще браузеры? Например, я не знаю ни одной пупочесалки с посгресом. Все, панихиду заказывать?

Очевидно же, нет.
Да я уже по истерике парой веток рядом понял. Помочь можно чем-нибудь? Я в жаббере есличо

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 07:59 (ссылка)
Это не отменяет факт его почтенного возраста.

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

Разумеется, ведь они готовят его на основе старого кода.

Ну, то есть, старый код оказался не таким уже неподходящим для этой задачи, верно?

Он еще и орехоколок не делал. Что за аргумент такое, причем тут вообще браузеры?

Ну хорошо, можно не так поставить вопрос.
Можно провести голосование: если бы сейчас коллеги собрались бы писать браузер, на каком языке они бы его писали?
За пределами PHP-сообщества, я думаю, голоса были бы не в пользу Java сейчас.

Да я уже по истерике парой веток рядом понял. Помочь можно чем-нибудь? Я в жаббере есличо

Окей, я продолжу здесь, потому что это интересная тема.
Зачем люди ходят на конференции и собеседования? Чтобы получить обратную связь. В первом случае обратная связь будет от, условно говоря, прогрессивной тусовки, лица из которой спят наяву (обкурившись гашиша, хехе) и видят сны о будущем индустрии. Во втором случае обратная связь будет от тех, кто платит нам деньги. В обоих случаях появляется некое направление дальнейшего движения. Как ты понимаешь, горизонты познания бесконечны, и хотелось бы их, по возможности, сузить. Я могу изучить язык Nemerle, но не хочу. Я хочу изучить что-нибудь, что а) даст возможность обезопасить мой доход, б) даст возможность не заснуть на первых 20 страницах книги "это самое за 21 день".
И вот, я иду на собеседование, и слышу там все то же самое, что слышал пять лет назад. Ну и, зачем ходил? Что мне изучать, ESB и OSB? О, круто, а энергетики бесплатно выдадут? Или мне сесть и повторять Core Java до тех пор, пока я не начну во сне разговаривать методами из java.util? Отличные перспективы.
Ты вот спрашиваешь, чем помочь, выходы два:
1) Всем хорошим срочно собраться и убить всех плохих,
2) Упразднить товарно-денежные отношения, всю власть передать поэтам и философам, каждому выдать по 20 рабов и далее действовать как в книге "Город Солнца" или любой аналогичной.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 08:59 (ссылка)
блядь, ну ты реально зажег

Саша, ты пошел на интервью в Люксофт для UBS и реальне думал, что тебя будут спрашивать о хорошем, добром и вечном?

ну это как если бы тебе выдали, ну не знаю, какую ты там еду больше всего не любишь, ты знаешь что ты её не любишь - но попробовал и потом накропал аццкий псто на тему "бля! оно говно!!!111"

не ходи на собеседования в люксофт, и будет тебе моральное спокойствие и плюс десять лет к жизни

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 09:02 (ссылка)
Ну, кто звал, к тому и пошел.
А куда еще?
Все остальные отваливаются на этапе обсуждения зарплатной вилки.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 13:41 (ссылка)
то есть ты хочешь сказать, что ты озвучил вилку, тебе сказали "ок, говно вопрос" и позвали на интервью?

так не бывает

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 13:44 (ссылка)
Не поел, почему не бывает?
Я всегда сразу называю вилку, чтобы время зря не терять.
Но по определенным причинам (известно, каким), с люксом это не совсем срабатывает.
Хотя весной они меня не позвали именно из-за вилки.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 13:45 (ссылка)
видать, тебе попался какой=то неправильный хр

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 13:48 (ссылка)
Ну я фиг знает, а что должен был сделать правильный HR?
Кстати, никакого фидбэка по последнему собеседованию от них нет до сих пор, "чтоб они сгорели нахуй", как пишет в FrF коллега Корвалол.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-22 14:24 (ссылка)
Саш, это большой бодишоп с собстыенным бардаком внутри, так что забей

тем более что все равно ты там работать не собирался, даже за нужные тебе дегни

(Ответить) (Уровень выше)


(Анонимно)
2011-07-22 13:58 (ссылка)
Ну если желание не сменить работу, а потрещать о перспективах, то можно и не отваливаться на этапе обсуждения зп самому, нет?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2011-07-22 14:03 (ссылка)
А технологии обычно приходят в описании позиции - то есть, можно, конечно, их начать обсуждать на уровне технических лидов и так далее, но, если технологии уже выбраны, вряд ли их поменяют. Я этого наелся уже, в конце концов, раз в год попадается кто-нибудь с подходящей зарплатной вилкой, после чего заходит разговор за технику. Пока меня никто не удивил в нужную сторону.

(Ответить) (Уровень выше)


[info]zamotivator@lj
2011-07-21 07:55 (ссылка)
Это уже мелкие недоработки реализации физического плана (executor'а)

(Ответить) (Уровень выше)


[info]alexclear@lj
2011-07-21 03:22 (ссылка)
В идеале оптимизатор должен все такие варианты сводить в AntiSemiJoin и не ебать мозги

Ты не поверишь - он именно так и делает.

(Ответить) (Уровень выше)


[info]antilamer@lj
2011-07-21 16:36 (ссылка)
Чёто я не понимаю, нафиг это вообще знать, это не концептуальный вопрос а зубрежка возможностей оптимизатора конкретной версии конкретной бд. План запроса к реальным данным надо посмотреть и все.

(Ответить) (Ветвь дискуссии)


[info]jdevelop@lj
2011-07-21 18:37 (ссылка)
+500

(Ответить) (Уровень выше)