Подольский городской форум

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

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

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

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 Анастасия,

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

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

Акуз писал(а):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

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

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

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

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

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

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

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

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

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

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

J.Rico

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

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

Акуз писал(а):J.Rico

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Акуз

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

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

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

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

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

Акуз писал(а): ничего не понимаю!

эт бывает

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

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

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

Акуз писал(а): я сегодня не курил, потому не понимаю

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

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

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

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

Акуз

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

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

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

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

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

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

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

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

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