Здравствуйте, Alex.Che, Вы писали:

AC>Привет, Merle!
AC>Вы пишешь 19 марта 2004:

R>>> Когда join быстрее получается — делаю его. Не догма. Выбирается то, что быстрее.
M>> Дык в том-то и засада, что сейчас быстрее один join, а через полчаса другой... Не на выбираешься.

AC>Тут ты не прав. Давайте обсуждать вкусовые качества устриц с теми кто их пробовал ;о)

не, ну ты странный... пол-часа назад у меня в таблице ордеров было 100 записей, а щаз стало 10 000. и всё. порядок джоинов совсем другой должен быть. да мало ли как меняется статистика.

Привет, Merle!
Вы пишешь 19 марта 2004:

AC>> Тут ты не прав. Давайте обсуждать вкусовые качества устриц с теми кто их пробовал ;о)
M> Ты про каких устриц? И в чем я не прав?
M> Хочешь сказать, что в большинстве систем оптимальный план большинства запросов определяетя на этапе разработки?

Ты не съезжай, не съезжай ;о)
Я про то, что вынесено в subject этой ветки.

--
With best regards, Alex Cherednichenko.

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>Здравствуйте, Alex.Che, Вы писали:

AC>>Привет, Merle!
AC>>Вы пишешь 19 марта 2004:

R>>>> Когда join быстрее получается — делаю его. Не догма. Выбирается то, что быстрее.
M>>> Дык в том-то и засада, что сейчас быстрее один join, а через полчаса другой... Не на выбираешься.

AC>>Тут ты не прав. Давайте обсуждать вкусовые качества устриц с теми кто их пробовал ;о)

_MM_>не, ну ты странный... пол-часа назад у меня в таблице ордеров было 100 записей, а щаз стало 10 000. и всё. порядок джоинов совсем другой должен быть. да мало ли как меняется статистика.

Хм... И Если в приведенном мной примере есть индекс по DOC.NUM и Client_ID — первичный ключ у CLIENT, то куда что изменится?! Селективность первичного ключа?

Здравствуйте, Romkin, Вы писали:

R>Хм... И Если в приведенном мной примере есть индекс по DOC.NUM и Client_ID — первичный ключ у CLIENT, то куда что изменится?! Селективность первичного ключа?

да нет, я в селекте проверяю овнера для ордера, и еще отдел просматривающего и еще дату создания ордера и еще... короче много всего.

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>не, ну ты странный... пол-часа назад у меня в таблице ордеров было 100 записей, а щаз стало 10 000. и всё. порядок джоинов совсем другой должен быть. да мало ли как меняется статистика.

Точнее даже, я что, не знаю примерного соотношения мощностей отношений? Вот еще... Если в одной таблице не более 1000 записей (ну просто не может быть), а остальные растут неограниченно (порядка 100000 записей и более), то вполне можно понять, что выбрать.
А вот если сопоставимо — то да, join. Но разуумненько, благо выбор есть.

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>Здравствуйте, Romkin, Вы писали:

R>>Хм... И Если в приведенном мной примере есть индекс по DOC.NUM и Client_ID — первичный ключ у CLIENT, то куда что изменится?! Селективность первичного ключа?

_MM_>да нет, я в селекте проверяю овнера для ордера, и еще отдел просматривающего и еще дату создания ордера и еще... короче много всего.

Ну согласись, это уже совершенно другой случай. Однако. Чем рассмотренный в заголовке, и даже чем рассмотренный мной. ТУт думать надо, смотреть, выбирать

Здравствуйте, Romkin, Вы писали:

R>Ну согласись, это уже совершенно другой случай. Однако. Чем рассмотренный в заголовке, и даже чем рассмотренный мной. ТУт думать надо, смотреть, выбирать

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

Привет, _MarlboroMan_!
Вы пишешь 19 марта 2004:

R>> Ну согласись, это уже совершенно другой случай. Однако. Чем рассмотренный в заголовке, и даже чем рассмотренный мной. ТУт
R>> думать надо, смотреть, выбирать

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

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

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Оптимизатор конечно, слабенький, но чтоб хаять, нужно таки его знать (имхо).
Не, погоди... Ты внимательно весь топик прочитал?
Про оптимизатор, как таковой, речь не идет. В предлагаемых примерах на него как раз забивают.

Здравствуйте, Alex.Che, Вы писали:

AC>Ты не съезжай, не съезжай ;о)
И в мыслях не было...

AC>Я про то, что вынесено в subject этой ветки.
В subject'е этой ветки — некорректное поведение IB с SELECT'ами и, как следствие — слабость оптимизатора.

Привет, Merle!
Вы пишешь 19 марта 2004:

AC>> Оптимизатор конечно, слабенький, но чтоб хаять, нужно таки его знать (имхо).
M> Не, погоди... Ты внимательно весь топик прочитал?
M> Про оптимизатор, как таковой, речь не идет. В предлагаемых примерах на него как раз забивают.

Опять стрелки переводишь? ;о)
Мой праведный гнев вызвала фраза господина _MarlboroMan_'а:
=========Beginning of the citation==============
не, ну ты странный... пол-часа назад у меня в таблице ордеров было 100 записей,
а щаз стало 10 000. и всё. порядок джоинов совсем другой должен быть.
да мало ли как меняется статистика.
=========The end of the citation================
Потому как IB, в плане обновления статистики, ведёт себя несколько не так как вы привыкли на MS SQL.
В данном случае, это как раз и есть его особенности.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Опять стрелки переводишь? ;о)
Нет, это все-таки ты не внимательно читаешь... =)

AC>Потому как IB, в плане обновления статистики, ведёт себя несколько не так как вы привыкли на MS SQL.
В данном случае твой праведный гнев совершенно не по делу, поскольку эта фраза Мальборо относилась к сообщению в котором предлагалось вообще збить на статистику и все делать в ручную.
И Мальборо этой фразой, как раз показывал недостатки такого подхода, тоесть отстаивал ровно твою точку зрения, что даже в IB статистика нужна.

Другое дело, что IB не всегда в полной мере может ей распорядиться, и вот это вот его особенности.

Привет, Merle!
Вы пишешь 19 марта 2004:

[Sorry, skipped]
AC>> Потому как IB, в плане обновления статистики, ведёт себя несколько не так как вы привыкли на MS SQL.
M> В данном случае твой праведный гнев совершенно не по делу, поскольку эта фраза Мальборо относилась к сообщению в котором
M> предлагалось вообще збить на статистику и все делать в ручную. И Мальборо этой фразой, как раз показывал недостатки такого
M> подхода, тоесть отстаивал ровно твою точку зрения, что даже в IB статистика нужна.

Ну, это он пущай сам скажет, чего он имел в виду

M> Другое дело, что IB не всегда в полной мере может ей распорядиться, и вот это вот его особенности.

Опять съехал...
Я про актуализацию статистики, а ты опять "...заунывную песню свою"...

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Ну, это он пущай сам скажет, чего он имел в виду

считай сказал

AC>Опять съехал...
AC>Я про актуализацию статистики, а ты опять "...заунывную песню свою"...

а нафига она нужна если у тебя либо руками план строится, либо вероятность крэша?

Здравствуйте, Alex.Che, Вы писали:

AC>Я про актуализацию статистики, а ты опять "...заунывную песню свою"...
Да при чем тут статистика? Ей никто пользоваться не собирается.
Давай по шагам:
1. У оптимизатора проблемы.
2. Пердлагается жестко задвинуть оптимизатор и подумать за него.
3. Обсуждаются недостатки этого подхода.
4. Тут ты, сосвоей статистикой... Зачем? Если мы пользуемся статистикой, мы скатываемся к случаю (1) — у оптимизатора проблемы. (чтобы понять что такое рекурсия, надо сначала понять, что такое рекурсия)

Нас сейчас не интересует ни статистика, ни способы ее сбора и обработки.

Привет, _MarlboroMan_!
Вы пишешь 19 марта 2004:

[Sorry, skipped]
AC>> Я про актуализацию статистики, а ты опять "...заунывную песню свою"...

M> а нафига она нужна если у тебя либо руками план строится, либо вероятность крэша?

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

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Опять съехал...
AC>Я про актуализацию статистики, а ты опять "...заунывную песню свою"...


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

Привет, Merle!
Вы пишешь 19 марта 2004:

AC>> Я про актуализацию статистики, а ты опять "...заунывную песню свою"...
M> Да при чем тут статистика? Ей никто пользоваться не собирается.

Это потому что один человек в этой конференции заявил, что он всё планирует руками,
и сразу оба модератора решили, что для IB это есть нормально и все IB-шники так поступают?

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>У кого это "у тебя"? Ты мою базу видел, или мои запросы?..
AC>Не нужно эмоциональной пыли

считай, что вместо "у тебя" я написал "у разработчика для/под СУБД interbase"

и "Не нужно эмоциональной пыли" (с)

Здравствуйте, Alex.Che, Вы писали:

AC>Это потому что один человек в этой конференции заявил, что он всё планирует руками,
AC>и сразу оба модератора решили, что для IB это есть нормально и все IB-шники так поступают?
Эээээ... спокуха на лице Мы обсуждали конкретную ситуацию, почему все IB'шники решили, что мы с ними не дружим..