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

S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.

И чего же ты себя тут не забанил?


S>И мне каждый раз интересно — вдруг это я тупой чего-то интересного не знаю о СУБД.

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

Правда, в итоге умудрился сам себя обмануть:

— тут утверждаешь, что для случаях "простого индекса" и для случая FK мы всё-равно имеем "один и тот же план запроса" (С), позволяя себе на основании этого лишь утверждения рассуждать о квалификации собеседника.

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

Но и там тоже "работаешь" ниже пояса, со своим свинством: "обычно так делают невежды".

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

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

===================
Отчего произошёл такой знатный залёт?
— потому что каждый раз тщательно уходишь от технических подробностей.

Что характерно, почему-то уходишь от разных их, да еще во втором случае как на аргумент умудрился сослаться на ту самую подробность, от которой тщательно дистанцировался в первом случае. Ну и кто ты после таких "трюков"? ))
А я знал! (С)

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

Я:
— тождественость оценки сверху не принципиальна с т.з. современных ресурсов, их характеристик и обычного объема истории курсов валют. Разница в подробностях реализации более катастрофическая, т.е. разница оценки снизу, и составляет не проценты, а разы, порой до порядка.

Причины-то известные.
Самая первая из них — если рассматривать "точный" FK vs "неточный" max(change_date) where change_date<=doc_date — первый сценарий слияния можно выполнять по отсортированным регионам независимо, т.е. единая отсортированная последовательность дат и док-тов не нужна.

В первом случае можно в каждый момент времени рассматривать лишь некий домен (область значений), т.е., можно как оптимизировать алгоритмы чтения областей данных с диска/памяти (пользоваться допустимостью перестановки последовательности чтения страниц и/или их регионов), так и вовсе распараллелить вычисления по ядрам процессора — ведь у нас на руках есть кое-какие важные гарантии относительно даных, не? Имея на руках гарантии целостности FK мы можем избавиться от лишних двух проверок на каждом цикле (через скриптовый движок, на секундочку), и в каждый момент времени можем рассматривать лишь одну запись (кардинально увеличивая параллелизм всей базы, на секундочку).

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

На фоне всего этого вижу спекуляцию (или просто делаешь вид, что не понимаешь), насчёт того, что inner join по FK — он в базе имеет "железную" наиболее эффективную реализацию для большинства популярных сценариев — как раз по числовым типам данных, к которым относятся так же даты.

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


S>Не разочаровывайте меня — покажите, откуда могут взяться тормоза в современном движке, который уж 15 лет как перестал выполнять full scan в таких подзапросах.

Да не, это ты разочаровываешь откровенным передёргиванием:

1. RANK, OVER, PARTITION появилась с версии MS SQL 2008, т.е. широко могла быть освоена индустрией не ранее 2009-2010-х годов (никто же не кинется срочно переписывать имеющийся код, верно?)

2. В любом случае, такие выражения эквивалентно выразимы через join или where и обсуждаемое изначально условие, т.е. это вопрос вкуса, а не "плана запросов"; т.е. мимо более чем полностью — обычный пук в лужу;

3. ответ по ссылке содержит ошибку.

Ты не обратил на п.3 внимание?
Или обратил, но понадеялся, что мы не обратим?

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

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

S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.

И чего же ты себя тут не забанил?


S>И мне каждый раз интересно — вдруг это я тупой чего-то интересного не знаю о СУБД.

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

Правда, в итоге умудрился сам себя обмануть:

— тут утверждаешь, что для случаях "простого индекса" и для случая FK мы всё-равно имеем "один и тот же план запроса" (С), позволяя себе на основании этого лишь утверждения рассуждать о квалификации собеседника.

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

Но и там тоже "работаешь" ниже пояса, со своим свинством: "обычно так делают невежды".

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

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

===================
Отчего произошёл такой знатный залёт?
— потому что каждый раз тщательно уходишь от технических подробностей.

Что характерно, почему-то уходишь от разных их, да еще во втором случае как на аргумент умудрился сослаться на ту самую подробность, от которой тщательно дистанцировался в первом случае. Ну и кто ты после таких "трюков"? ))
А я знал! (С)

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

Я:
— тождественость оценки сверху не принципиальна с т.з. современных ресурсов, их характеристик и обычного объема истории курсов валют. Разница в подробностях реализации более катастрофическая, т.е. разница оценки снизу, и составляет не проценты, а разы, порой до порядка.

Причины-то известные.
Самая первая из них — если рассматривать "точный" FK vs "неточный" max(change_date) where change_date<=doc_date — первый сценарий слияния можно выполнять по отсортированным регионам независимо, т.е. единая отсортированная последовательность дат и док-тов не нужна.

В первом случае можно в каждый момент времени рассматривать лишь некий домен (область значений), т.е., можно как оптимизировать алгоритмы чтения областей данных с диска/памяти (пользоваться допустимостью перестановки последовательности чтения страниц и/или их регионов), так и вовсе распараллелить вычисления по ядрам процессора — ведь у нас на руках есть кое-какие важные гарантии относительно даных, не? Имея на руках гарантии целостности FK мы можем избавиться от лишних двух проверок на каждом цикле (через скриптовый движок, на секундочку), и в каждый момент времени можем рассматривать лишь одну запись (кардинально увеличивая параллелизм всей базы, на секундочку).

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

На фоне всего этого вижу спекуляцию (или просто делаешь вид, что не понимаешь), насчёт того, что inner join по FK — он в базе имеет "железную" наиболее эффективную реализацию для большинства популярных сценариев — как раз по числовым типам данных, к которым относятся так же даты.

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


S>Не разочаровывайте меня — покажите, откуда могут взяться тормоза в современном движке, который уж 15 лет как перестал выполнять full scan в таких подзапросах.

Да не, это ты разочаровываешь откровенным передёргиванием:

1. RANK, OVER, PARTITION появилась с версии MS SQL 2008, т.е. широко могла быть освоена индустрией не ранее 2009-2010-х годов (никто же не кинется срочно переписывать имеющийся код, верно?)

2. В любом случае, такие выражения эквивалентно выразимы через join или where и обсуждаемое изначально условие, т.е. это вопрос вкуса, а не "плана запросов"; т.е. мимо более чем полностью — обычный пук в лужу;

3. ответ по ссылке содержит ошибку.

Ты не обратил на п.3 внимание?
Или обратил, но понадеялся, что мы не обратим?

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