Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Стоит ли ввести SEMI JOIN ?
Адназначна
41,2%
 (7)
Многое не учтено (описать в комментах)
5,9%
 (1)
Легко заменяется (описать в комментах), нафиг
11,8%
 (2)
Ещё одна фигня в разрез стандартам, нафиг
23,5%
 (4)
Фиолетово
11,8%
 (2)
С точки зрения маркетинга бесперспективно
5,9%
 (1)
Голосование открыто только для зарегистрированных пользователей.
Проголосовало: 17  

Синтаксис:
<join_type> ::= [ { INNER | { { LEFT | RIGHT | FULL | SEMI } [ OUTER ] } } [ <join_hint> ] ] JOIN
<select_list> ::= ...
      | Exists( { table_name | view_name | table_alias } ) -- Bit type "function"
<search_condition> | <condition> ::= ...
      | Exists( { table_name | view_name | table_alias } ) = [ 0 | 1 ]

Собствено ссылка на последнее обсуждение.
7 май 12, 19:31    [12521174]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
аноним
Легко заменяется
А "описать в комментах" западло?
Ок, анулируем этот голос.
7 май 12, 21:39    [12521485]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Чтобы долго не ходили по ссылкам, опишу ещё раз:
Mnior
JOIN конструкивный элемент запроса, а Exists нет, его нельзя многократно использовать.
Если возожно воспользоваться (логика позволяет) вместо Exists - LEFT JOIN, то это меньшее из зол. Можно выражение PK [NOT] NULL использовать:
1. Явно в WHERE
2. В выражениях в любом месте, SELECT, CASE и т.п.
3. За пределами VIEW, где этот LEFT JOIN описан, опять же в любом месте
Следовательно, в зависимости от описаных условий план будет подстраиваться.

В случае Exists это нельзя. Либо многократно повторять код, либо описать в одном CASE поле, но постановка по нему условия "= [ 0 | 1]" не даёт догадаться оптимизатору оптимизировать запрос должным образом.

Да, этим мы заплитили тем, что соединение не будет SEMI (хотя это недоработка оптимизатора), но хотя бы порядок чтения/связывания будет выбрано правильно (на основании статистики).
Или всё равное не понятно/не учтено?
8 май 12, 10:18    [12522519]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Как я полагаю, invm проголосовал.
8 май 12, 11:44    [12522751]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Mnior
Чтобы долго не ходили по ссылкам, опишу ещё раз:
Mnior
JOIN конструкивный элемент запроса, а Exists нет, его нельзя многократно использовать.
Если возожно воспользоваться (логика позволяет) вместо Exists - LEFT JOIN, то это меньшее из зол. Можно выражение PK [NOT] NULL использовать:
1. Явно в WHERE
2. В выражениях в любом месте, SELECT, CASE и т.п.
3. За пределами VIEW, где этот LEFT JOIN описан, опять же в любом месте
Следовательно, в зависимости от описаных условий план будет подстраиваться.

В случае Exists это нельзя. Либо многократно повторять код, либо описать в одном CASE поле, но постановка по нему условия "= [ 0 | 1]" не даёт догадаться оптимизатору оптимизировать запрос должным образом.

Да, этим мы заплитили тем, что соединение не будет SEMI (хотя это недоработка оптимизатора), но хотя бы порядок чтения/связывания будет выбрано правильно (на основании статистики).
Или всё равное не понятно/не учтено?
В случае CROSS|INNER|LEFT|RIGHT|FULL|UNION|NATURAL JOINа результат SELECTа содержит поля обеих таблиц.
Когда применяется EXISTS, поля таблиц из подзапроса не попадают в результат (EXISTS в WHERE, а не во FROMе).
Что же будет в результирующем наборе SELECTа из второй таблицы в результате SEMI JOINа?
8 май 12, 12:02    [12522833]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
invm
Member

Откуда: Москва
Сообщений: 9827
Mnior
Как я полагаю, invm проголосовал.
Не угадали
8 май 12, 12:36    [12523006]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
step_ks
Member

Откуда:
Сообщений: 936
iap
Что же будет в результирующем наборе SELECTа из второй таблицы в результате SEMI JOINа?

Я так понимаю, что ничего, кроме "Да/Нет" в каком-либо виде.

Навроде
select so.id
      ,has_columns = e.has
     from sysobjects so
          outer apply (select 1 where exists(select * from syscolumns sc where sc.id=so.id)) e (has)


Mnior, правильно понимаю?
8 май 12, 12:56    [12523105]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
step_ks
iap
Что же будет в результирующем наборе SELECTа из второй таблицы в результате SEMI JOINа?

Я так понимаю, что ничего, кроме "Да/Нет" в каком-либо виде.

Навроде
select so.id
      ,has_columns = e.has
     from sysobjects so
          outer apply (select 1 where exists(select * from syscolumns sc where sc.id=so.id)) e (has)


Mnior, правильно понимаю?
Это уродливо. Извините.
Если так, то EXISTS лучше.
8 май 12, 13:03    [12523139]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
step_ks
Member

Откуда:
Сообщений: 936
iap
step_ks
пропущено...

Я так понимаю, что ничего, кроме "Да/Нет" в каком-либо виде.

Навроде
select so.id
      ,has_columns = e.has
     from sysobjects so
          outer apply (select 1 where exists(select * from syscolumns sc where sc.id=so.id)) e (has)


Mnior, правильно понимаю?
Это уродливо. Извините.
Если так, то EXISTS лучше.
Есть немного. Но что значит "exists" лучше? Тут и есть exists. Я учитывал требования, указанные Mnior'ом - вывалить полем во вью, не копипастить в select - листе и в where, без case-ов вида "case when exists". Можно то же самое через cte или derived table, да.
Возможно, с введением SEMI, оптимизатор было легче научить понимать, чего от него хотят.
8 май 12, 14:09    [12523479]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
step_ks
Member

Откуда:
Сообщений: 936
step_ks
Возможно, с введением SEMI, оптимизатор было легче научить понимать, чего от него хотят.
Опечатка, имелось ввиду "было бы легче".
8 май 12, 14:13    [12523501]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
iap
Что же будет в результирующем наборе SELECTа из второй таблицы в результате SEMI JOINа?
Два вариант:
1. Ничего
2. Битовое поле Exists

Ну давайте я с фланга зайду: А как насчёт PIVOT | UNPIVOT ?
8 май 12, 14:49    [12523643]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
step_ks, Не учтено всё:
SELECT	 O.[object_id]
FROM	sys.objects	O
	OUTER APPLY (
		SELECT	Convert(Bit,1)
		WHERE	Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])
		)	E(has)
WHERE	E.has IS NULL

SELECT	 O.[object_id]
FROM	sys.objects	O
WHERE	NOT Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])
+ Смотрим планы
  |--Filter(WHERE:([Expr1056] IS NULL))
       |--Nested Loops(Left Outer Join, OUTER REFERENCES:([o].[id]))
            |--Filter(WHERE:(has_access('CO',[sys].[sysschobjs].[id] as [o].[id])=(1)))
            |    |--Clustered Index Scan(OBJECT:([sys].[sysschobjs].[clst] AS [o]), WHERE:([sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [sys].[sysschobjs].[pclass] as [o].[pclass]=(1)))
            |--Nested Loops(Left Semi Join)
                 |--Constant Scan(VALUES:(((1))))
                 |--Filter(WHERE:(has_access('CO',[sys].[syscolpars].[id])=(1)))
                      |--Clustered Index Seek(OBJECT:([sys].[syscolpars].[clst]), SEEK:([sys].[syscolpars].[id]=[sys].[sysschobjs].[id] as [o].[id] AND [sys].[syscolpars].[number]=(0)) ORDERED FORWARD)

  |--Merge Join(Left Anti Semi Join, MERGE:([o].[id])=([sys].[syscolpars].[id]), RESIDUAL:([sys].[syscolpars].[id]=[sys].[sysschobjs].[id] as [o].[id]))
       |--Filter(WHERE:(has_access('CO',[sys].[sysschobjs].[id] as [o].[id])=(1)))
       |    |--Clustered Index Scan(OBJECT:([sys].[sysschobjs].[clst] AS [o]),  WHERE:([sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [sys].[sysschobjs].[pclass] as [o].[pclass]=(1)) ORDERED FORWARD)
       |--Stream Aggregate(GROUP BY:([sys].[syscolpars].[id]))
            |--Filter(WHERE:(has_access('CO',[sys].[syscolpars].[id])=(1)))
                 |--Clustered Index Scan(OBJECT:([sys].[syscolpars].[clst]),  WHERE:([sys].[syscolpars].[number]=(0)) ORDERED FORWARD)
Кагрится почувствуйте разницу.
8 май 12, 15:03    [12523698]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Конечно вы можете возразить:
SELECT	 O.[object_id]
FROM	sys.objects	O
	OUTER APPLY (
		SELECT	Convert(Bit,0)
		WHERE	NOT Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])
		)	E(has)
WHERE	E.has = 0
Тока сами понимаете, что не получится сразу и то и другое.

Опять же, пишете вы VIEW и написали что-то там. Но одновременно написать:
SELECT * FROM dbo.vwFooBar WHERE Bla_Exists = 0
SELECT * FROM dbo.vwFooBar WHERE Bla_Exists = 1
Не получится.

Ok, вы продублируете (закроем на это убожество глаза):
SELECT * FROM dbo.vwFooBar WHERE Bla_Exists = 1
SELECT * FROM dbo.vwFooBar WHERE Bla_Not_Exists = 1
Тогда такое будет не эффективно, т.к. при обращении к двум колонкам одновременно будет двойное обращение к под-запросу, что убивает всё на корню.
8 май 12, 16:00    [12523943]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
step_ks
Member

Откуда:
Сообщений: 936
Mnior, всё так. Да и не агитирую за этот способ, привел его в качестве примера, дабы уточнить, правильно ли понял вашу тему.
Думаете, введение новой синтаксической конструкции сразу обеспечит годные планы для обоих случаев?
9 май 12, 13:31    [12526360]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Давайте вообще императивный подъязык введем, ага. Где будем серверу объяснять что и как делать. А что, идея неплохая!
9 май 12, 19:37    [12527189]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
step_ks
Думаете, введение новой синтаксической конструкции сразу обеспечит годные планы для обоих случаев?
Это (изменений оптимизатора) думаю самый веский аргумент против. Ани итак "отупили" оптимизатор по некоторым параметрам с 2005 версии в угоду скорости компиляции. Отодвигая решение архитектурной проблемы (у которой видеться 2 пути решения: а) пре-компиляция парсинг запросов на стороне клиента; б) кеширование базовых структур запросов).

По идее никакой особенностей и существенных изменений нет. Ключевые особенности смены планов лежит только в WHERE, разницы между [NOT] Exists() и X.Exists = [ 0 | 1 ] нет. При множественном использовании это обычная "вычисляемая" колонка.
Интересные случаи могут возникать только если захочется оптимизировать дальше. К примеру:
A.Exists [ = | != ] B.Exists


С другой стороны вариант с APPLY на-а-амного дороже в плане анализа. Т.е. простота и чёткость написания приводит к быстроте компиляции. Если они это сделают, то и баг с LEFT JOIN решиться.

Есть ещё один вопрос в синтаксисе. На самом деле написания явного Exists = [ 0 | 1 ] в WHERE практически означает INNER. Но вводить его равносильно написать явно Exists(), т.е. излишество синтаксиса, но зато нагляднее. С другой стороны само по себе SEMI JOIN не означает условие отбора, а связку и следовательно равносильно обычному группированному LEFT JOIN. Т.е. опять таки обычный сахарок (который M$ не любила).

Лично мне $р@ть, на эти отмазки (3 вида сахара), для меня самое главное гибкость и я именно подозреваю одновременное использование и OUTER и явного WHERE, но в разных местах кода (см. идеология VIEW). И тут не отвертеться.
9 май 12, 20:48    [12527358]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SomewhereSomehow
Давайте вообще императивный подъязык введем, ага. Где будем серверу объяснять что и как делать.
Вы о чём?
Тут всё как раз декларативно. Это нормальные реляционные операторы. Мы серверу ничего не навязываем он волен заблуждаться в выборе плана.
Вас видимо смутило само название связки?

Многое не учтено
Мужики, давайте быть конструктивными. Аргументируйте в каментах точку зрения!
9 май 12, 21:01    [12527388]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SomewhereSomehow
Давайте вообще императивный подъязык введем, ага.
На самом деле текущая плохая продуманность языка и его реализации приводит к повсеместной (вынужденной и не только) императивщине в коде.

PS: Ссори, завёлся.
9 май 12, 21:14    [12527429]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
iap, 12523643
Вопросы остались?
10 май 12, 11:21    [12528709]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Mnior
iap, 12523643
Вопросы остались?
Нет.
Но чего-то как-то...
В общем, я ещё не голосовал.
10 май 12, 11:53    [12528938]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
Mnior
step_ks, Не учтено всё:
SELECT	 O.[object_id]
FROM	sys.objects	O
	OUTER APPLY (
		SELECT	Convert(Bit,1)
		WHERE	Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])
		)	E(has)
WHERE	E.has IS NULL

SELECT	 O.[object_id]
FROM	sys.objects	O
WHERE	NOT Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])
+
+ Смотрим планы
  |--Filter(WHERE:([Expr1056] IS NULL))
       |--Nested Loops(Left Outer Join, OUTER REFERENCES:([o].[id]))
            |--Filter(WHERE:(has_access('CO',[sys].[sysschobjs].[id] as [o].[id])=(1)))
            |    |--Clustered Index Scan(OBJECT:([sys].[sysschobjs].[clst] AS [o]), WHERE:([sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [sys].[sysschobjs].[pclass] as [o].[pclass]=(1)))
            |--Nested Loops(Left Semi Join)
                 |--Constant Scan(VALUES:(((1))))
                 |--Filter(WHERE:(has_access('CO',[sys].[syscolpars].[id])=(1)))
                      |--Clustered Index Seek(OBJECT:([sys].[syscolpars].[clst]), SEEK:([sys].[syscolpars].[id]=[sys].[sysschobjs].[id] as [o].[id] AND [sys].[syscolpars].[number]=(0)) ORDERED FORWARD)

  |--Merge Join(Left Anti Semi Join, MERGE:([o].[id])=([sys].[syscolpars].[id]), RESIDUAL:([sys].[syscolpars].[id]=[sys].[sysschobjs].[id] as [o].[id]))
       |--Filter(WHERE:(has_access('CO',[sys].[sysschobjs].[id] as [o].[id])=(1)))
       |    |--Clustered Index Scan(OBJECT:([sys].[sysschobjs].[clst] AS [o]),  WHERE:([sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [sys].[sysschobjs].[pclass] as [o].[pclass]=(1)) ORDERED FORWARD)
       |--Stream Aggregate(GROUP BY:([sys].[syscolpars].[id]))
            |--Filter(WHERE:(has_access('CO',[sys].[syscolpars].[id])=(1)))
                 |--Clustered Index Scan(OBJECT:([sys].[syscolpars].[clst]),  WHERE:([sys].[syscolpars].[number]=(0)) ORDERED FORWARD)
Кагрится почувствуйте разницу.

имхо какой-то непоказательный пример с запросами к представлениям.
10 май 12, 11:55    [12528950]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Мистер Хенки
имхо какой-то непоказательный пример с запросами к представлениям.
Вас непонятно, не аргументированно, или вы к оформлению придираетесь?
Да для оформления нужно многое дописать и хороший пример придумать.
+
Даже на простой можно сказать "напишите 100500 раз Exist":
CREATE VIEW cbo.vwUsers AS
SELECT	 U.ID
	,U.[Login]
	,U.Name
	,E.IsAdmin
FROM	dbo.[User] U OUTER APPLY (
		SELECT	Convert(Bit,1)
		WHERE	Exists(
			SELECT	*
			FROM	dbo.UserGroup G
			WHERE	    G.[User] = U.ID
				AND G.[Group] = 'Admin' -- dbo.fnGroupID('Admin') or JOIN
		)	E(IsAdmin)
	-- SEMI JOIN dbo.UserGroup G ON G.[User] = U.ID AND G.[Group] = 'Admin' -- dbo.fnGroupID('Admin') or JOIN
GO ---------------------------------------------
SELECT	 P.Title
	,U.Name
FROM	     dbo.Posts	P
	JOIN dbo.vwUser	U ON P.[User] = U.ID
WHERE	U.IsAdmin IS NULL
	-- U.IsAdmin = 0
GO ---------------------------------------------
SELECT	 P.Title
	,U.Name
FROM	     dbo.Posts	P
	JOIN dbo.vwUser	U ON P.[User] = U.ID
WHERE	U.IsAdmin = 1
GO ---------------------------------------------
SELECT	 CASE	WHEN U.IsAdmin = 1
		THEN '[Admin] '
		ELSE ''
		END + P.Title
	,P.[Text]
FROM	     dbo.Posts	P
	JOIN dbo.vwUser	U ON P.[User] = U.ID
GO
Простите, воображение у меня не работает сейчас в этом направлении.
10 май 12, 16:08    [12531121]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
Mnior
Мистер Хенки
имхо какой-то непоказательный пример с запросами к представлениям.
Вас непонятно, не аргументированно, или вы к оформлению придираетесь?
Да для оформления нужно многое дописать и хороший пример придумать.


Просто пример был на представлениях основан и мне показалось что выбор оптимизатором Merge Join для запроса с not exists не вполне обусловлен именно тем, что мы используем not exists(извиняюсь за каламбур), а с корее тем, что работаем с представлениями. Я читал тут и проверял разные способы получения Anti Semi Join и если мы работаем с таблицами, то получался именно план с AntiSemiJoin при использовании Not Exists. Вот что я имел ввиду, когда говорил про не совсем удачный пример
10 май 12, 16:27    [12531334]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
iap
Но чего-то как-то...
Да, не по феншую. Мне тоже это не нравиться.
Даже вот и в FULL тоже не так гладко:
Mnior
А вот на FULL-е мы получаем первую бяку - нет алиаса отношения нет доступа к его ключевым элементам - IsNull/Coalesce в зубы.
Иногда не стоит на красоте зацикливаться, это особенность модели как таковой, точнее я б сказал самой теории.

И главное, чем я с вами согласен, это надо не просто посмотреть 3 секунды и ляпнуть (типи "не нуна"/нуна), а попытаться в повсеместной работе "использовать" и почувствовать. Тут нужно быть сильным теоретиком с большой практикой, которые испытали все подходы собственной задницей.
Если кто-то рвётся попить пивка и закусить шашлычком, чем подумать "а что если", "а как", "и чем лучше" - я не заставляю. :) У людей разные основные цели (и взгляды) в жизни. И второе, никто никуда не спешит (падумашь подождать годик, десяток).
---------
И в добавок, дайте мне покажите минус. Один хороший/добротный минус. Пожайлуста.
10 май 12, 16:44    [12531490]     Ответить | Цитировать Сообщить модератору
 Re: Стоит ли ввести SEMI JOIN ?  [new]
step_ks
Member

Откуда:
Сообщений: 936
Мистер Хенки
Mnior
пропущено...
Вас непонятно, не аргументированно, или вы к оформлению придираетесь?
Да для оформления нужно многое дописать и хороший пример придумать.


Просто пример был на представлениях основан и мне показалось что выбор оптимизатором Merge Join для запроса с not exists не вполне обусловлен именно тем, что мы используем not exists(извиняюсь за каламбур), а с корее тем, что работаем с представлениями.


Представления тут не причем. Вот с двух разных баз.

SELECT	 O.[object_id]
FROM	sys.objects	O
WHERE	NOT Exists(SELECT * FROM sys.columns C WHERE C.[object_id] = O.[object_id])

Rows                 Executes             StmtText                                                                                                                                                                                                                  
-------------------- -------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1056 1 SELECT O.[object_id]
1056 1 |--Hash Match(Left Anti Semi Join, HASH:([o].[id])=([tempdb].[sys].[syscolpars].[id]))
2548 1 |--Filter(WHERE:(has_access('CO',[tempdb].[sys].[sysschobjs].[id] as [o].[id])=(1)))
2548 1 | |--Clustered Index Scan(OBJECT:([tempdb].[sys].[sysschobjs].[clst] AS [o]), WHERE:([tempdb].[sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [tempdb].[sys].[sysschobjs].[pclass] as [o].[pclass]=(1)))
7754 1 |--Filter(WHERE:(has_access('CO',[tempdb].[sys].[syscolpars].[id])=(1)))
7754 1 |--Index Scan(OBJECT:([tempdb].[sys].[syscolpars].[nc]), WHERE:([tempdb].[sys].[syscolpars].[number]=(0)))

Rows                 Executes             StmtText                                                                                                                                                                                                                      
-------------------- -------------------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 1 SELECT O.[object_id]
3 1 |--Nested Loops(Left Anti Semi Join, OUTER REFERENCES:([o].[id]))
53 1 |--Filter(WHERE:(has_access('CO',[tst].[sys].[sysschobjs].[id] as [o].[id])=(1)))
53 1 | |--Clustered Index Scan(OBJECT:([tst].[sys].[sysschobjs].[clst] AS [o]), WHERE:([tst].[sys].[sysschobjs].[nsclass] as [o].[nsclass]=(0) AND [tst].[sys].[sysschobjs].[pclass] as [o].[pclass]=(1)))
50 53 |--Top(TOP EXPRESSION:((1)))
50 53 |--Filter(WHERE:(has_access('CO',[tst].[sys].[syscolpars].[id])=(1)))
50 53 |--Clustered Index Seek(OBJECT:([tst].[sys].[syscolpars].[clst]), SEEK:([tst].[sys].[syscolpars].[id]=[tst].[sys].[sysschobjs].[id] as [o].[id] AND [tst].[sys].[syscolpars].[number]=(0)) ORDERED FORWARD)
10 май 12, 16:44    [12531491]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить