И да, ещё, само по себе решение JOIN UserInfo U ON 1 = 1 какое-то странное.
Допустим у нас есть 10 пользователей и 10 записей в таблице UserInfo. Когда мы сделаем присоединение именно таким образом, то у нас в результате получится 100 строк. Разницу в производительности между 10 и 20 пользователями почувствовать сложно, но вот если у нас 10 000 пользователей, то наступит ад, а если их миллион, то сами подумайте)
Я бы не доверил вам проектировать БД своих проектов. Без обид ;)
P.S.: К слову, если у нас будет миллион пользователей и мы сделаем присоединение ON 1=1 без лимитов, то выборка будет состоять из 1 000 000 000 000 (1 триллион) строк.
SELECT U.FIO, U.PhoneNumber, U.Address, T.Column1, T.Column2, T.Column3
FROM Table1 T
JOIN UserInfo U ON 1 = 1
не эквивалентно
SELECT
(SELECT FIO FROM UserInfo) as FIO,
(SELECT PhoneNumber FROM UserInfo) as PhoneNumber,
(SELECT Address FROM UserInfo) as Address,
T.Column1, T.Column2, T.Column3
FROM Table1 T
Последний запрос вообще ошибку вернёт, т.к. вложенные запросы никак не агрегированы. А если использовать агрегацию, то результат будет отличаться от того, что мы увидим с первым запросом.
Вложенные запросы — это плохо. Запросы в JOIN'ах — это тоже не хорошо и используют их в крайних мерах.
Из моей практики, практически всегда можно решить задачи без вложенных запросов, используя только JOIN'ы, GROUP BY, HAVING и агрегирующих процедур, в таком случае планировщик запросов составит правльный план и использует все средства для оптимизации (индексы, кеш и т.п.). Именно такие решения будут являться правильными! Но это ИМХО. И я не знаю тонкостей работы MS SQL, может там всё наоборот.
INSERT Session.MainSubQuery
SELECT * FROM Table1;
INSERT Session.SubQuery
SELECT * FROM Table2;
SELECT *
FROM Session.MainSubQuery M
LEFT JOIN Session.SubQuery Q1 ON Q1.id = M.id AND Q1.Param = 1
LEFT JOIN Session.SubQuery Q2 ON Q2.id = M.id AND Q2.Param = 2
LEFT JOIN Session.SubQuery Q3 ON Q3.id = M.id AND Q3.Param = 3
LEFT JOIN Session.SubQuery Q4 ON Q4.id = M.id AND Q4.Param = 4;
*facepalm* Отвратительное решение! Выше объяснили почему.
И я правильно понял, что вы создаёте процедуры «на лету» и дропаете их?
Тут много до чего можно докопаться…
Но хочу сразу предупредить, что с MS SQL я не имел дел никогда и не знаю о тонкостях его работы вообще ничего. За-то есть большой опыт работы с PostgreSQL, Firebird, MySQL, SQLite (это из РСУБД).
1.
Замена Left Join на Union
Как эти подходы можно сравнивать? Ведь схема выборки изменится!
2. Решения
SELECT
T1.*, T2.*
FROM Table1 T1
JOIN Table2 T2 ON T2.Id = T1.Id AND COALESCE(T2.Column, 0) = COALESCE(T1.Column, 0)
и
SELECT
T1.*, T2.*
FROM Table1 T1
JOIN Table2 T2 ON T2.Id = T1.Id
WHERE COALESCE(T2.Column, 0) = COALESCE(T1.Column, 0)
Должны быть идентичными. Вы выполните оба запроса (с EXPLAIN-ом) и посмотрите какая будет схема выполнения. Я уверен на 95%, что планировщик запросов сделает их практических идентичными. А для того, чтобы COALESCE(T2.Column, 0) = COALESCE(T1.Column, 0) «искалось» по индексу — нужно создать для этого функциональные индексы.
И определённо, запрос
SELECT
T1.*, T2.*
FROM Table1 T1
JOIN Table2 T2 ON T2.Id = T1.Id AND T2.Column = T1.Column
UNION
SELECT
T1.*, T2.*
FROM Table1 T1
JOIN Table2 T2 ON T2.Id = T1.Id AND T2.Column IS NULL AND T1.Column IS NULL
будет более ресурсоёмким по сравнению с вариантом выше и функциональными индексами. Посмотрите сами на план запроса.
3.
Проблема в том, что многие думают, что подзапрос SubQuery выполнится один раз, и далее будет браться только результат и подставляется там, где он далее потребуется.
Я, конечно, могу ошибаться, но в PostgreSQL будет задействован именно результат, а не будет подставляться запрос целиком каждый раз, когда вы его будете использовать. Во всяком случае, у меня есть основания так полагать, т.к. оптимизировал несколько раз таким образом запросы и план запроса был «легче» с WITH, чем с подставленными целыми запросами. Думаю, что в MS SQL должно быть так же, это же логично! Хотя я и могу ошибаться, т.к., выше уже писал, что ничерта не шарю в тонкостях работы MS SQL.
SELECT
T.Column1,
T2.Column3,
T.Column2
FROM Table1 T
JOIN (SELECT Max(Column) as Column3 FROM Table2) T2 ON 1 = 1
Очень необычное решение ON 1 = 1. С таким условием у вас T2.Column3 будет всегда одинаковым. Впрочем в «не кошерном» варианте ситуация такая же. А в MS SQL нельзя вот так?
SELECT
T.Column1,
MAX(T2.Column) AS Column3,
T.Column2
FROM Table1 T
JOIN Table2 T2 ON T2.T_id = T.id
GROUP BY T.Column1, T.Column2
Если так можно, то именно это решение будет являться наиболее приемлемым. ИМХО!
Пользовался подобной вещью для ST, только названия не помню, может даже именно этот плагин, кстати, очень похож. Неудобства появляются когда у вас не один проект в дереве, а несколько и когда вам недостаточно простого add/pull/commit/push, а нужен ещё и git flow… В итоге вернулся к терминалу.
А в целом по статье: такую статью можно написать про каждый плагин, а их там туева хуча. Любой кто задумывался над вопросом интеграции ST и git, может легко найти нужный плагин или группу плагинов, почитать readme.md на гитхабе и попробовать его в деле. Не вижу смысла в целой статье, хотя тут и есть симпатичные скриншоты.
Мне, к счастьюсожалению, вас не понять…
Там где не хватает "<command> --help" всегда можно заюзать "man <command>", далее, если всё ещё не понятно как делать (что бывает редко) — ищем решение в Интернете. Но это не в винде, поэтому мне вас и не понять :)
Это сильно снижает уровень входа, что является как плюсом, так и минусом. С одной стороны можно быстро начать делать что-то более-менее рабочее, в этом я с вами согласен. Но минус порождаемый этим плюсом просто ни в какие рамки не лезет!
Я понимаю создание клик-гайдов для пользователей, это нормально, но для инжереров и программистов — это просто кошмар. Нас в университете учили находить решения, вникать в суть проблемы/задачи, понимать процесс. А с клик-гайдом единственный процесс, который тебе нужно понять — это то, что необходимо в нужном окне нажать на нужную кнопочку и ввести нужную комбинацию символов.
И именно это, на мой взгляд, является основной причиной такого большого количества низкоквалифицированных работников.
Ещё один минус (сейчас камень полетит в Microsoft), по некоторым вопросам/задачам вообще невозможно найти что-то кроме клик-гайда! Возможно я, конечно, плохо ищу, но, как говорится, осадочек остался…
P.S.: Сейчас опять меня будут минусовать любители Microsoft)))
Ну вот, теперь поплатился за это =(
Зачем люди носят шлёпанцы/тапки/сандали с носками?
А вообще статья занятная, проснулось желание посмотреть книгу Кормена по алгоритмам.
JOIN UserInfo U ON 1 = 1какое-то странное.Допустим у нас есть 10 пользователей и 10 записей в таблице UserInfo. Когда мы сделаем присоединение именно таким образом, то у нас в результате получится 100 строк. Разницу в производительности между 10 и 20 пользователями почувствовать сложно, но вот если у нас 10 000 пользователей, то наступит ад, а если их миллион, то сами подумайте)
Я бы не доверил вам проектировать БД своих проектов. Без обид ;)
P.S.: К слову, если у нас будет миллион пользователей и мы сделаем присоединение
ON 1=1без лимитов, то выборка будет состоять из 1 000 000 000 000 (1 триллион) строк.не эквивалентно
Последний запрос вообще ошибку вернёт, т.к. вложенные запросы никак не агрегированы. А если использовать агрегацию, то результат будет отличаться от того, что мы увидим с первым запросом.
Вложенные запросы — это плохо. Запросы в JOIN'ах — это тоже не хорошо и используют их в крайних мерах.
Из моей практики, практически всегда можно решить задачи без вложенных запросов, используя только JOIN'ы, GROUP BY, HAVING и агрегирующих процедур, в таком случае планировщик запросов составит правльный план и использует все средства для оптимизации (индексы, кеш и т.п.). Именно такие решения будут являться правильными! Но это ИМХО. И я не знаю тонкостей работы MS SQL, может там всё наоборот.
*facepalm* Отвратительное решение! Выше объяснили почему.
И я правильно понял, что вы создаёте процедуры «на лету» и дропаете их?
Но хочу сразу предупредить, что с MS SQL я не имел дел никогда и не знаю о тонкостях его работы вообще ничего. За-то есть большой опыт работы с PostgreSQL, Firebird, MySQL, SQLite (это из РСУБД).
1. Как эти подходы можно сравнивать? Ведь схема выборки изменится!
2. Решения и
Должны быть идентичными. Вы выполните оба запроса (с EXPLAIN-ом) и посмотрите какая будет схема выполнения. Я уверен на 95%, что планировщик запросов сделает их практических идентичными. А для того, чтобы
COALESCE(T2.Column, 0) = COALESCE(T1.Column, 0)«искалось» по индексу — нужно создать для этого функциональные индексы.И определённо, запрос будет более ресурсоёмким по сравнению с вариантом выше и функциональными индексами. Посмотрите сами на план запроса.
3.
Я, конечно, могу ошибаться, но в PostgreSQL будет задействован именно результат, а не будет подставляться запрос целиком каждый раз, когда вы его будете использовать. Во всяком случае, у меня есть основания так полагать, т.к. оптимизировал несколько раз таким образом запросы и план запроса был «легче» с WITH, чем с подставленными целыми запросами. Думаю, что в MS SQL должно быть так же, это же логично! Хотя я и могу ошибаться, т.к., выше уже писал, что ничерта не шарю в тонкостях работы MS SQL.
P.S.: буду рад, если меня поправят :)
Очень необычное решение
ON 1 = 1. С таким условием у вас T2.Column3 будет всегда одинаковым. Впрочем в «не кошерном» варианте ситуация такая же. А в MS SQL нельзя вот так?Если так можно, то именно это решение будет являться наиболее приемлемым. ИМХО!
Но Вин Дизель не фейковый же! =)
www.youtube.com/watch?v=yOX6JF9gABU
Путину уже бросили вызов Вин Дизель и Барак Обама.
А в целом по статье: такую статью можно написать про каждый плагин, а их там туева хуча. Любой кто задумывался над вопросом интеграции ST и git, может легко найти нужный плагин или группу плагинов, почитать readme.md на гитхабе и попробовать его в деле. Не вижу смысла в целой статье, хотя тут и есть симпатичные скриншоты.
счастьюсожалению, вас не понять…Там где не хватает "
<command> --help" всегда можно заюзать "man <command>", далее, если всё ещё не понятно как делать (что бывает редко) — ищем решение в Интернете. Но это не в винде, поэтому мне вас и не понять :)Я понимаю создание клик-гайдов для пользователей, это нормально, но для инжереров и программистов — это просто кошмар. Нас в университете учили находить решения, вникать в суть проблемы/задачи, понимать процесс. А с клик-гайдом единственный процесс, который тебе нужно понять — это то, что необходимо в нужном окне нажать на нужную кнопочку и ввести нужную комбинацию символов.
И именно это, на мой взгляд, является основной причиной такого большого количества низкоквалифицированных работников.
Ещё один минус (сейчас камень полетит в Microsoft), по некоторым вопросам/задачам вообще невозможно найти что-то кроме клик-гайда! Возможно я, конечно, плохо ищу, но, как говорится, осадочек остался…
P.S.: Сейчас опять меня будут минусовать любители Microsoft)))