дифченки программистки жгут

[Господин ПЖ]

юмор спицифичиский т.е. программисткий не все поймут,

прислала наша дифченка которая оптмизирует некий запрос, я вот не пойму толи она дура толи еще что-то, я даже предложил повесить это письмо на нашу "доску почета":

Погляди сам, сколько времени уйдет на выполнение запроса:

SELECT
EQBGPF.cref,
eqcust.GFCUS,
EQBGPF.BGFNM1 AS BGFNM1,
EQBGPF.BGFNM2 AS BGFNM2,
EQBGPF.BGFNM3 AS BGFNM3,
EQBGPF.BGDTBR AS BGDTBR_,
EQBGPF.BGSNOM as f_DUL_Number,
EQBGPF.BGORGD as DULORG,
eqcust.SVPZIP as f_PostIndex,
EQcust.SVNA3 as f_Rayon,
EQcust.SVNA4 as f_Settlement,
EQcust.SVNA1 as f_StreetFROM
[dbo].[eqcust] AS eqcust,
[dbo].[EQBGPF] AS EQBGPF

- результат неприятно удивит.
Могу только сказать, что он на моей машине выполнялся 2 часа 50 минут и выдал результат в 9 млн. записей. Это тебе о чем-нибудь говорит? По-моему, даже без where это несколько "многовато".
С уважением, XXXXXXX Анастасия,

[Desecrator]

она что, SQL впервые в жизни видит?.... смешного нет ничего, только тупо....

[Raven]

Breth
Видимо таки второй - запрос-то выполнился.

[Desecrator]

SELECT
EQBGPF.cref,
eqcust.GFCUS,
EQBGPF.BGFNM1 AS BGFNM1,
EQBGPF.BGFNM2 AS BGFNM2,
EQBGPF.BGFNM3 AS BGFNM3,
EQBGPF.BGDTBR AS BGDTBR_,
EQBGPF.BGSNOM as f_DUL_Number,
EQBGPF.BGORGD as DULORG,
eqcust.SVPZIP as f_PostIndex,
EQcust.SVNA3 as f_Rayon,
EQcust.SVNA4 as f_Settlement,
EQcust.SVNA1 as f_StreetFROM
[dbo].[eqcust] AS eqcust,
[dbo].[EQBGPF] AS EQBGPF

распространение служебной информации, ты уволен

[Господин ПЖ]

она что, SQL впервые в жизни видит?.... смешного нет ничего, только тупо....

да нет не впервый

[Господин ПЖ]

распространение служебной информации, ты уволен

если бы у тут опубликовал твой счет и остаток средств, то был бы уволен и посажен

[просто соня]

Акуз
а в чем фишка?

[Desecrator]

Sne_gyrochka, имхо объяснять тебе в чём фишка прийдется столько же времени, сколько этот запрос выполняется....

[просто соня]

Breth
Я НЕ ДУРА, я пойму, очень хочется посмеятся(по нашему, по програмистски)

[Desecrator]

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

[J.Rico]

...я чета не догнал... глухой селект из двух таблиц. А джоин где? И по скольку записей в каждой таблице?
Может девочку научить джоину и все-таки рекомендовать where? А то я чета даже без теста и не предполагаю чего получится...

[Господин ПЖ]

J.Rico

в том и фича что нет ни джойна ни where и чего она хочет я понять не могу, да еще и наезды делает

[J.Rico]

Акуз
Не, ну по крайней мере запрос-то выполнился! Значит не все потеряно для общества в лице девочки-программистки
Я однажды учился рекурсию писАть. Естественно допустил циклическую ошибку. Через 5 часов 100%й загрузки проца решил тормознуть это дело... Записей в таблицу было набросано просто непомерно!
"Если программист допустил ошибку, это не значит что он не прав, это значит что он - человек!"

[дасвидос :)]

J.Rico

в том и фича что нет ни джойна ни where и чего она хочет я понять не могу, да еще и наезды делает

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

[Господин ПЖ]

см. задча стояла отыскать клиентов по различным критериям ФИО, ДР, номер ДУЛ, старое ФИО старый ДУЛ и т.д. т.е. нужно понять если у нас такой клиент. и если есть вывести их на экран.
клиентаская инфа находится в двух таблицах см. FROM связаны они по полю CREF.

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

кстати история вообще смешно начиналась, она сначала из связала как надо и говорит что если написать JOIN то он работает 1 секунды а если WHERE то 27, я ей сказал что пусть учит SQL ибо время это относительно сами понимаете нагрузки сервера, сети и т.д. а надо смотреть план запроса, а план будет одинаковым.

кстати разработчки базы (англичане) клоуны еще те.

[Брателло]

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

[Господин ПЖ]

Брателло
мы не айтишники

[Господин ПЖ]

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

[J.Rico]

мне сегодня эта дифченка прислала результаты тестирования

Исходники фстудию!

[Господин ПЖ]

J.Rico
Да дело не в них, а то что она в результатах отобразила, типа нифига ничего не правилино, бизнес-процессы не правильный, меня хватило только на первый пункт отчеты, а дальше хотело только ругаться матом!

[Господин ПЖ]

это обычное перемножение множеств, может девочка именно этого хотела ?

Рассажи мне о практическом примении результатов запроса из двух связанных таблиц без джойна?

[дасвидос :)]

Акуз

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

[Господин ПЖ]

recent
Я имею ввиду не скорость а практический смысл

[дасвидос :)]

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

[Господин ПЖ]

ничего не понимаю!

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

[дасвидос :)]

ничего не понимаю!

эт бывает

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

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

[Господин ПЖ]

не Бумбыч, я сегодня не курил, потому не понимаю

[J.Rico]

я сегодня не курил, потому не понимаю

Я тож не курил, но понял, допустим вводим условие - что есть только сосиски МОлочные, и хотим отчет - юзеров 72 года рождения имеющих возможность съесть имеющиеся сосиски.

[дасвидос :)]

блин
че-т жрать даже захотелось

[Господин ПЖ]

J.Rico
Нуда как минимум нужна еще одна таблица т.е. связь между сосисками и юзверами, а без этой таблицы ничего путного не получишь, так пердёшь один

[J.Rico]

Акуз
Нет не нужна.
Перемножение получится такое - количество записей результатов запроса будет записи1 * записи2. Т.е. если в таблице сосисок 3 хаписи, а в таблице юзеров 10, то результирующее число записей - 30 (каждой записи одной таблицы соответствуют ВСЕ записи другой). Потому в исходном варианте и получилось слишком много записей. Патамушта без джоина.

[дасвидос :)]

Акуз

а вот необязательно, зачем плодить связи лишние пользователь-сосиска ?
да и строк будет немеренно, на фик оно надо ? если можно сделать все красивее и проще ?

[Господин ПЖ]

Бумбыч я не ф куриваю, вот смотри, у тебя такие таблицы:

Пользователи ПФ
(
Код пользователя,
Имя пользователя
)

Типы сосисок
(
код сосиски,
имя сосиски
)

И что ты сможешь получить?

[дасвидос :)]

полное пересечение пользователь-сосиска

а если в таблицу сосисок добавить признак, то ...

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

[Господин ПЖ]

еще раз и по русски