Сообщение Re[88]: The door от 29.07.2018 16:29
Изменено 29.07.2018 16:57 vdimas
Re[88]: The door
Здравствуйте, Sinclair, Вы писали:
V>>Собсно, удивило то, что в MS SQL план запроса не зависел от того, использовалась ли для обсуждаемых неординарных соединений конструкция join, или простое where.
V>>Т.е. это уже было дело вкусовщины автора запроса.
S>Отож. Известный факт, во всех учебниках по проектированию RDBMS описан.
Это ты какие-то уже поздние учебники имеешь виду, походу. ))
Такой join Оракл научился только с 5-й версии, а до него умел только DB2.
Собсно, не смотря на свою объективную тормознутость относительно конкурентов и непростыми процедурами обслуживания, MS SQL 6.x натурально подкупал удобством/всеядностью своего диалекта. Жрал всё подряд.
"Снижал порог входа", как стали говорить чуть позже.
Хотя, из-за такого "сниженного порога", когда рынок труда именно MS SQL наводнили полуграмотные админы (т.е. ушедшие в ДБА по причине недостаточно успешной карьеры "честным программистом") и это реноме "недостаточно несерьёзной БД" висит над MS SQL до сих пор. ))
V>>Ничего военного там нет — обычный составной кластерный индекс {код_валюты, дата_изменения_курса}, бо ширина индекса практически равна ширине таблицы.
S>Ещё раз поясню природу вопроса: "тяжесть" запроса определяется исключительно операциями, из которых состоит план запроса.
S>Удивительно не то, что MS SQL порождает одинаковый план для where, для join, и для subselect.
S>А то, что при грамотном построении индексов, порождается одинаковый план что для =, что для max(...) where ...<=...
Ясно ))
Ты опять тянешь нас в "медленные диски".
Не вырос еще из этих штанишек?
S>Не надо мне рассказывать про то, как вы боролись с замедлением таких запросов.
Я? ))
У меня вообще курсы в клиентском кеше лежали.
Я не мог позволить себе такие вычисления на серваке.
S>Лучше расскажите, откуда берётся замедление в пару секунд при джойне с историческими данными.
От рандтрипа на клиента, речь же была про 1С.
S>На примере плана запроса "если бы курсы были на каждый день" и плана запроса для "но курс на данную дату нужно вычислять по max(change_date) where change_date<=doc_date."
S>Ибо не должно там быть никаких тормозов, про которые вы рассказываете.
Ибо, сорри, но это нупство уже какое-то.
В первом случае мы имеем обычный внешний ключ и "железную" прямо в базе реализацию join по внешнему ключу.
Кароч, твои рассуждения имеют право на жизнь, если ты рассуждаешь сугубо о дисках.
Но курсы всегда лежат в оперативке, бо набор их смешной.
Указанная операция слияния по диапазонам технически медленнее операции слияния по внешнему ключу.
S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.
Разумеется, ты же ленишься проверять — просто из пальца себе что-то насосал и умничаешь.
Т.е. ты себе вообразил некую модель и согласно твоей модели — это одно и то же.
А то, что твоя модель не дотягивает и до 1% от фактической — всегда игноришь.
Я уже на второй подобный пост отвечаю.
Де-факто ты НИКОГДА не выжимал из базы максимальное быстродействие.
Твои примеры увеличения чего-то там в 50 раз всегда смешны.
Это как у меня по работе, например, ускорить операцию обработки из исходной в лоб 250 микросекунд до 20-ти микросекунд — это легко.
Но из 20-ти получить 12 — уже на порядок сложнее.
Из этих 12 получить затем 5-6 — в мире десятки людей всего, которые так могут.
Без ложной скромности.
Ты всегда хвастаешься первым сценарием, чем делаешь смешно.
Там даже не само это хвастовство смешно, а твоя попытка экстраполяции опыта из первого сценария на все остальные сценарии.
Это уже натуральная узколобость, сорри.
V>>Собсно, удивило то, что в MS SQL план запроса не зависел от того, использовалась ли для обсуждаемых неординарных соединений конструкция join, или простое where.
V>>Т.е. это уже было дело вкусовщины автора запроса.
S>Отож. Известный факт, во всех учебниках по проектированию RDBMS описан.
Это ты какие-то уже поздние учебники имеешь виду, походу. ))
Такой join Оракл научился только с 5-й версии, а до него умел только DB2.
Собсно, не смотря на свою объективную тормознутость относительно конкурентов и непростыми процедурами обслуживания, MS SQL 6.x натурально подкупал удобством/всеядностью своего диалекта. Жрал всё подряд.
"Снижал порог входа", как стали говорить чуть позже.
Хотя, из-за такого "сниженного порога", когда рынок труда именно MS SQL наводнили полуграмотные админы (т.е. ушедшие в ДБА по причине недостаточно успешной карьеры "честным программистом") и это реноме "недостаточно несерьёзной БД" висит над MS SQL до сих пор. ))
V>>Ничего военного там нет — обычный составной кластерный индекс {код_валюты, дата_изменения_курса}, бо ширина индекса практически равна ширине таблицы.
S>Ещё раз поясню природу вопроса: "тяжесть" запроса определяется исключительно операциями, из которых состоит план запроса.
S>Удивительно не то, что MS SQL порождает одинаковый план для where, для join, и для subselect.
S>А то, что при грамотном построении индексов, порождается одинаковый план что для =, что для max(...) where ...<=...
Ясно ))
Ты опять тянешь нас в "медленные диски".
Не вырос еще из этих штанишек?
S>Не надо мне рассказывать про то, как вы боролись с замедлением таких запросов.
Я? ))
У меня вообще курсы в клиентском кеше лежали.
Я не мог позволить себе такие вычисления на серваке.
S>Лучше расскажите, откуда берётся замедление в пару секунд при джойне с историческими данными.
От рандтрипа на клиента, речь же была про 1С.
S>На примере плана запроса "если бы курсы были на каждый день" и плана запроса для "но курс на данную дату нужно вычислять по max(change_date) where change_date<=doc_date."
S>Ибо не должно там быть никаких тормозов, про которые вы рассказываете.
Ибо, сорри, но это нупство уже какое-то.
В первом случае мы имеем обычный внешний ключ и "железную" прямо в базе реализацию join по внешнему ключу.
Кароч, твои рассуждения имеют право на жизнь, если ты рассуждаешь сугубо о дисках.
Но курсы всегда лежат в оперативке, бо набор их смешной.
Указанная операция слияния по диапазонам технически медленнее операции слияния по внешнему ключу.
S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.
Разумеется, ты же ленишься проверять — просто из пальца себе что-то насосал и умничаешь.
Т.е. ты себе вообразил некую модель и согласно твоей модели — это одно и то же.
А то, что твоя модель не дотягивает и до 1% от фактической — всегда игноришь.
Я уже на второй подобный пост отвечаю.
Де-факто ты НИКОГДА не выжимал из базы максимальное быстродействие.
Твои примеры увеличения чего-то там в 50 раз всегда смешны.
Это как у меня по работе, например, ускорить операцию обработки из исходной в лоб 250 микросекунд до 20-ти микросекунд — это легко.
Но из 20-ти получить 12 — уже на порядок сложнее.
Из этих 12 получить затем 5-6 — в мире десятки людей всего, которые так могут.
Без ложной скромности.
Ты всегда хвастаешься первым сценарием, чем делаешь смешно.
Там даже не само это хвастовство смешно, а твоя попытка экстраполяции опыта из первого сценария на все остальные сценарии.
Это уже натуральная узколобость, сорри.
Re[88]: The door
Здравствуйте, Sinclair, Вы писали:
V>>Собсно, удивило то, что в MS SQL план запроса не зависел от того, использовалась ли для обсуждаемых неординарных соединений конструкция join, или простое where.
V>>Т.е. это уже было дело вкусовщины автора запроса.
S>Отож. Известный факт, во всех учебниках по проектированию RDBMS описан.
Это ты какие-то уже поздние учебники имеешь виду, походу. ))
Такой join Оракл научился только с 5-й версии, а до него умел только DB2.
Собсно, не смотря на свою объективную тормознутость относительно конкурентов и непростыми процедурами обслуживания, MS SQL 6.x натурально подкупал удобством/всеядностью своего диалекта. Жрал всё подряд.
"Снижал порог входа", как стали говорить чуть позже.
Хотя, из-за такого "сниженного порога", когда рынок труда именно MS SQL наводнили полуграмотные админы (т.е. ушедшие в ДБА по причине недостаточно успешной карьеры "честным программистом") и это реноме "недостаточно несерьёзной БД" висит над MS SQL до сих пор. ))
V>>Ничего военного там нет — обычный составной кластерный индекс {код_валюты, дата_изменения_курса}, бо ширина индекса практически равна ширине таблицы.
S>Ещё раз поясню природу вопроса: "тяжесть" запроса определяется исключительно операциями, из которых состоит план запроса.
S>Удивительно не то, что MS SQL порождает одинаковый план для where, для join, и для subselect.
S>А то, что при грамотном построении индексов, порождается одинаковый план что для =, что для max(...) where ...<=...
Ясно ))
Ты опять тянешь нас в "медленные диски".
Не вырос еще из этих штанишек?
S>Не надо мне рассказывать про то, как вы боролись с замедлением таких запросов.
Я? ))
У меня вообще курсы в клиентском кеше лежали.
Я не мог позволить себе такие вычисления на серваке.
S>Лучше расскажите, откуда берётся замедление в пару секунд при джойне с историческими данными.
От рандтрипа на клиента, речь же была про 1С.
S>На примере плана запроса "если бы курсы были на каждый день" и плана запроса для "но курс на данную дату нужно вычислять по max(change_date) where change_date<=doc_date."
S>Ибо не должно там быть никаких тормозов, про которые вы рассказываете.
Ибо, сорри, но это нупство уже какое-то.
В первом случае мы имеем обычный внешний ключ и "железную" прямо в базе реализацию join по внешнему ключу.
Кароч, твои рассуждения имеют право на жизнь, если ты рассуждаешь сугубо о дисках.
Но курсы всегда лежат в оперативке, бо набор их смешной.
Указанная операция слияния по диапазонам технически медленнее операции слияния по внешнему ключу.
S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.
Разумеется, ты же ленишься проверять — просто из пальца себе что-то насосал и умничаешь.
Т.е. ты себе вообразил некую модель и согласно твоей модели — это одно и то же.
А то, что твоя модель не дотягивает и до 1% от фактической — всегда игноришь.
Я уже на второй подобный пост отвечаю.
Де-факто ты НИКОГДА не выжимал из базы максимальное быстродействие.
Твои примеры увеличения чего-то там в 50 раз всегда смешны.
Это как у меня по работе, например, ускорить операцию обработки из исходных в лоб 250 микросекунд до 20-ти микросекунд — это легко.
Но из 20-ти получить 12 — уже на порядок сложнее.
Из этих 12 получить затем 5-6 — в мире десятки людей всего, которые так могут.
Без ложной скромности.
Ты всегда хвастаешься первым сценарием, чем делаешь смешно.
Там даже не само это хвастовство смешно, а твоя попытка экстраполяции опыта из первого сценария на все остальные сценарии.
Это уже натуральная узколобость, сорри.
V>>Собсно, удивило то, что в MS SQL план запроса не зависел от того, использовалась ли для обсуждаемых неординарных соединений конструкция join, или простое where.
V>>Т.е. это уже было дело вкусовщины автора запроса.
S>Отож. Известный факт, во всех учебниках по проектированию RDBMS описан.
Это ты какие-то уже поздние учебники имеешь виду, походу. ))
Такой join Оракл научился только с 5-й версии, а до него умел только DB2.
Собсно, не смотря на свою объективную тормознутость относительно конкурентов и непростыми процедурами обслуживания, MS SQL 6.x натурально подкупал удобством/всеядностью своего диалекта. Жрал всё подряд.
"Снижал порог входа", как стали говорить чуть позже.
Хотя, из-за такого "сниженного порога", когда рынок труда именно MS SQL наводнили полуграмотные админы (т.е. ушедшие в ДБА по причине недостаточно успешной карьеры "честным программистом") и это реноме "недостаточно несерьёзной БД" висит над MS SQL до сих пор. ))
V>>Ничего военного там нет — обычный составной кластерный индекс {код_валюты, дата_изменения_курса}, бо ширина индекса практически равна ширине таблицы.
S>Ещё раз поясню природу вопроса: "тяжесть" запроса определяется исключительно операциями, из которых состоит план запроса.
S>Удивительно не то, что MS SQL порождает одинаковый план для where, для join, и для subselect.
S>А то, что при грамотном построении индексов, порождается одинаковый план что для =, что для max(...) where ...<=...
Ясно ))
Ты опять тянешь нас в "медленные диски".
Не вырос еще из этих штанишек?
S>Не надо мне рассказывать про то, как вы боролись с замедлением таких запросов.
Я? ))
У меня вообще курсы в клиентском кеше лежали.
Я не мог позволить себе такие вычисления на серваке.
S>Лучше расскажите, откуда берётся замедление в пару секунд при джойне с историческими данными.
От рандтрипа на клиента, речь же была про 1С.
S>На примере плана запроса "если бы курсы были на каждый день" и плана запроса для "но курс на данную дату нужно вычислять по max(change_date) where change_date<=doc_date."
S>Ибо не должно там быть никаких тормозов, про которые вы рассказываете.
Ибо, сорри, но это нупство уже какое-то.
В первом случае мы имеем обычный внешний ключ и "железную" прямо в базе реализацию join по внешнему ключу.
Кароч, твои рассуждения имеют право на жизнь, если ты рассуждаешь сугубо о дисках.
Но курсы всегда лежат в оперативке, бо набор их смешной.
Указанная операция слияния по диапазонам технически медленнее операции слияния по внешнему ключу.
S>Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.
Разумеется, ты же ленишься проверять — просто из пальца себе что-то насосал и умничаешь.
Т.е. ты себе вообразил некую модель и согласно твоей модели — это одно и то же.
А то, что твоя модель не дотягивает и до 1% от фактической — всегда игноришь.
Я уже на второй подобный пост отвечаю.
Де-факто ты НИКОГДА не выжимал из базы максимальное быстродействие.
Твои примеры увеличения чего-то там в 50 раз всегда смешны.
Это как у меня по работе, например, ускорить операцию обработки из исходных в лоб 250 микросекунд до 20-ти микросекунд — это легко.
Но из 20-ти получить 12 — уже на порядок сложнее.
Из этих 12 получить затем 5-6 — в мире десятки людей всего, которые так могут.
Без ложной скромности.
Ты всегда хвастаешься первым сценарием, чем делаешь смешно.
Там даже не само это хвастовство смешно, а твоя попытка экстраполяции опыта из первого сценария на все остальные сценарии.
Это уже натуральная узколобость, сорри.