(37) хватит пороть чушь. никакой разницы не будет

(39) абстракциями мыслишь. Скуль же не ими работает, а по одной записи выбирает, да сравнивает. Банальный перебор по индексу, и либо он сначала по ТЧ пойдет, либо по шапке. Последнее понятно быстрее. И он пойдет скорее по шапке, несмотря на косяк в запросе. Но запрос составлен через жопу я щетаю...

(40)(41)(42) нет

(41) ты точно понимаешь, как работает иннер джойн?

(44) Ты мне сейчас его логику объяснить что ли хочешь? Да, понимаю, выбираются записи, ключ которых есть и там и там. Но они не по волшебству там появляются, обычные циклы же по таблицам.

(44)
Ну вообще то разницы все таки есть, что к чему присоединять.
Если в таблицах N1 и N2 записей и , допустим, на кадждую запись из первой таблицы мы по индексу ищем записи во второй, то получается, что сложность поиска соответствующих записей во второй таблице на одну запись первой O(Ln(N2))
Тогда общая сложность получается O(N1*ln(N2))
Отсюда видно, что если N1>>N2, то выгоднее, чтобы было O(N2*ln(N1)), т.е. перебирать вторую и к ней джойнить первую.

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

(38) программист логически прав и в Select 1, 2, 3 и в Select * From Catalog.Банки, просто у программистов разная логика бывает )

(46) т.е. ты хочешь меня убедить, что искать N записей в таблице размером 10N выгоднее, чем искать 10N записей в таблице размером N?

(49) ага. Суди сам.
Упрощенно:
1. Ищем N записей в таблице 10*N с индексом

Перебираем записи цикл от 1 до N
{
Выполняем поиск в 10N по индексу - примерно Ln(10N) операций сравнения
}

Итого N*ln(10*N) операций = N*(ln(10)+ln(N))=N*ln(10)+N*Ln(N)

2. 1. Ищем 10*N записей в таблице N с индексом
Перебираем записи цикл от 1 до 10*N
{
Выполняем поиск в N по индексу - примерно Ln(N) операций сравнения
}

Итого 10*N*ln(N) операций = 9*N*ln(N)+N*ln(N)

===========
Теперь сравним N*ln(10)+N*Ln(N) и 9*N*ln(N)+N*ln(N)
Очевидно, что N*ln(10) < 9*N*ln(N) уже даже для N=2, не говоря уж о больших N

(50) При живой статистике оптимизатор скуля всегда раскручивает джойны в правильном направлении.

(50) формально соглашусь, но здесь есть нюанс

sda553 примерно Ln(10N) операций сравнения

O(ln(10N)), а не примерно ln(10N)
O(ln(10N)) - это и ln(10N), и 5 ln(10N), и 10 ln(10N)

(52) я сразу вроде и сказал, что О(N1*ln(N2))
Ну или более жизненные пример, понятный
У тебя есть бумажка с 10 фамилиями "Иванов, Петров, Сидоров...."
И есть телефонный справочник города Москвы, где все фамилии по алфавиту.(проиндексирован типа)

Тебе надо пользуясь этими двумя источниками составить записку [Фамилия] - [Номер телефона], для Иванова Петрова Сидорова....

У тебя есть два алгоритма на это
1. Перебирать все записи телефонного справочника г. Москвы от А до Я и взяв каждую запись оттуда сверять, не содержиться ли эта фамилия из справочника в бумажке с 10 фамилиями
2. Перебрать 10 фамилий из бумажки и для каждой фамилии находить соответствующую запись в телефонном справочнике г.москвы

Согласись 2-ой вариант оптимальнее будет

(48) добавь для корректности 3 условия для достоверности, по одному разговаривать то не о чем. Запрос был чисто для примера.
период между
реквизит составного
реквизит обычный

(55) а как количество условий влияет на производительность?

(57) вот мы и выясним повлияет или нет ...

(58) объясни смысл эксперимента?

Fynjy период между
реквизит составного
реквизит обычный

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

(59) Я это все понимаю, но вот инетерсно ...

(2) и правильно делает :)

(55) какая разница, джойн в любом случае будет идти по ссылке

(62) можно привести к типам и ограничить соединения нужными.
(63) не факт, вопрос в том, как транслирует запрос 1С в каком виде. Не удивлюсь, что через жопу ...

Fynjy Не удивлюсь, что через жопу ...

так проверь. будь мужиком, посмотри план запроса!

ГОСПОДА оптимизаторы. Приведите мне пример оптимального запроса, который позволил бы выявить контрагентов с одинаковым ИНН.

(54) хорошо, будем считать, что убедил.
но если взять пример "Справочник со 100 абонентами и список с 10 фамилиями", то уже не всё так радужно

(66)
select distinct contr1.ref
from
contr1 inner join contr2 on contr1.ref<>contr2.ref and contr1.inn=contr2.inn

Кстати, вижу прямо только что в типовом УТП

					И Номенклатура В
						(ВЫБРАТЬ РАЗЛИЧНЫЕ
							Документ.РасходныйОрдерНаТовары.Товары.Номенклатура
						ИЗ
							Документ.РасходныйОрдерНаТовары.Товары
						ГДЕ
							Документ.РасходныйОрдерНаТовары.Товары.Ссылка = &ДокументСсылка)

Так что девочка идет лесом )

(68) давай пример, там делов то на 1 мин

(67) а я это сразу сказал

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

(72) убедил

(74) я так не думаю

(75) ну... запрос в (70) как-то еще можно переписать?

(76) это откровенная жопа, а не запрос ...

(71)

select
 Контрагенты.Ссылка
 ,count(distinct Контрагенты.ИНН) as ИНН
from
      Справочник.Контрагенты as Контрагенты
group by
      Контрагенты.Ссылка
having
      count(distinct Контрагенты.ИНН)>1

(78) чем лучше (69)

(77)да ладно [smile=^_^]
давай продолжим после того, как ты нам покажешь как 1С транслировала запросы из (0)?

(78) Не проканает

(81) да ладно? а я ведь проверю

Честно сказать, в лом смотреть, но могу предположить, что первый запрос транслируется во второй при исполнении:) Что есть " РеализацияТоваровУслугТовары.Ссылка.Склад" - неявное соединение:):)

(82) проверь

(82) нужно количество различные

(84) У тебя получилось наоборот по смыслу, выявить контрагентов у которых одному конртагенту соответствует более одного ИНН. А я так понял надо выявить разных контрагентов с одним одинаковым ИНН

Запрос - 0.28сек:

ВЫБРАТЬ
	КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Контрагенты.Ссылка) КАК Ссылка,
	Контрагенты.ИНН
ПОМЕСТИТЬ ТаблицаИНН
ИЗ
	Справочник.Контрагенты КАК Контрагенты

СГРУППИРОВАТЬ ПО
	Контрагенты.ИНН

ИМЕЮЩИЕ
	КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Контрагенты.Ссылка) > 1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	Контрагенты.Ссылка,
	Контрагенты.ИНН
ИЗ
	Справочник.Контрагенты КАК Контрагенты
ГДЕ
	Контрагенты.ИНН В
			(ВЫБРАТЬ
				ТаблицаИНН.ИНН
			ИЗ
				ТаблицаИНН КАК ТаблицаИНН)

Запрос - 3.34 сек:

ВЫБРАТЬ
	Контрагенты.Ссылка,
	Контрагенты.ИНН КАК ИНН,
	Контрагенты1.Ссылка КАК Ссылка1,
	Контрагенты1.ИНН КАК ИНН1
ИЗ
	Справочник.Контрагенты КАК Контрагенты
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
		ПО (НЕ Контрагенты.Ссылка = Контрагенты1.Ссылка)
			И Контрагенты.ИНН = Контрагенты1.ИНН

(87) да, только первый вариант, ну можно еще вложенный запрос и внутреннее соединение

(87) это разные по смыслу запросы, смотри (86)

на собеседовании задали этот вопрос. я написал запрос №1. мой запрос унесли на проверку "местному прогу". когда "пришел ответ от прога" - мне его не сказали, но сказали, что на этом собеседование закончено, со мной свяжутся.

уверен, тот мега прог был авторов запроса №2. но ни разу не тестировал производительность.

(85) а я чё написал?

(91) ааа, пропустил. да, запрос верный. но для вывода самих контрагентов нужен еще запрос.

(93) а ну да,... теперь одинаковые по смыслу

(94) первый запрос быстрее на порядок

(92) в (78) запрос не верный

(87) Первый запрос не быстрее будет соединением во второй части? Или их там 10 штук?

(95) кто сказал что на порядок, я например вообще не дождался его окончания ) там полное декартово соединение

(95) нифига. все зависит от количества записей. если контрагентов меньше 50, то запрос sda - быстрее

(97) верный, но не полный

первый запрос в (87)
select с группировкой O(N)

второй запрос в (87)
O(N^2)

так что да,
твой вариант оптимальнее, чем (69)

(99) я проверил. контрагентов более 3000.

(97) сфигали?

(106) группировка по ссылке - у ссылки всегда один ИНН, не?
p.s. но идея верна

(107) ах, ну, да. я просто писал напрямую в форум.
группировать по ИНН надо, конечно

(106) у одного контрагента не могут быть несколько ИНН

короче ИМХО правильный вариант такой

ВЫБРАТЬ
	Контрагенты.Ссылка,
	Контрагенты.ИНН
ИЗ
	Справочник.Контрагенты КАК Контрагенты
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
			Контрагенты.ИНН КАК ИНН
		ИЗ
			Справочник.Контрагенты КАК Контрагенты
		ГДЕ
			Контрагенты.ИНН <> ""
		
		СГРУППИРОВАТЬ ПО
			Контрагенты.ИНН
		
		ИМЕЮЩИЕ
			КОЛИЧЕСТВО(Контрагенты.ИНН) > 1) КАК ВложенныйЗапрос
		ПО Контрагенты.ИНН = ВложенныйЗапрос.ИНН

а..не, не все так радужно
ВЫБРАТЬ
Контрагенты.Ссылка,
Контрагенты.ИНН
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
Контрагенты.ИНН В
(ВЫБРАТЬ
ТаблицаИНН.ИНН
ИЗ
ТаблицаИНН КАК ТаблицаИНН)

Этот запрос имеет сложность N^2 если ТаблицаИНН сравнима с таблицей контрагенты и отсутствии индекса по ИНН.

Так что запрос резко подведет в производительности если двойников по ИНН много очень

(110) ты еще вложенность добавил. смертный грех для эксперта.

MIK у одного контрагента не могут быть несколько ИНН

да всё, я же уже написал (109)

MIK Контрагенты.ИНН <> ""

это что? финт, чтобы отключить индекс, который там может быть? )

Бешеная Нога смертный грех для эксперта.

вложенность в данном случае будет стопудово быстрее создания временной таблицы

Бешеная Нога смертный грех для эксперта

ахаха, чушь )

(115) типовые долго от вложенных избавлялись, особенно в части зупа

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

(с)

(103) да лажанул я наспех, признаю. Но конторы которые проводят собеседование как в (90) мне все равно не нравятся, правильнее было бы дать возможность оценить сложность алгоритма исполнения получившегося запроса, после чего предложить эту сложность "упростить" при таких то сяких то допущениях

(87) потесть на своих данных, есть ли какая-нибудь разница

select
 Контрагенты.ИНН
 ,count(distinct Контрагенты.Ссылка) as ИНН
from
      Справочник.Контрагенты as Контрагенты
group by
      Контрагенты.ИНН
having
      count(distinct Контрагенты.Ссылка)>1

select
 Контрагенты.ИНН
 ,count(Контрагенты.ИНН) as ИНН
from
      Справочник.Контрагенты as Контрагенты
group by
      Контрагенты.ИНН
having
      count(Контрагенты.ИНН)>1

(117) :) Такие безапелляционные утверждения... Не работали люди с большими базами, с денормализованными базами. Индексы на временные таблицы не создавали...

(115) и в чём состоит чушь?

(120) оба O(N) просто перебрать все строки таблицы алгоритму

(123) чисто для интереса

(124) второй запрос с очепяткой - или так и задумано?
select
Контрагенты.ИНН
,count(Контрагенты.ИНН) as ИНН

(117) без временных, но с вложенными. пиши с вложенными. только контору свою назови, чтобы знать куда ходить не надо.

(126) давай забьем что в этом случае с задвоенными ИНН ВТ не будет быстрее вложенного?

я тоже повсеместно использую ВТ, но это не значит что это панацея

Sorm Такие безапелляционные утверждения

вовсе нет:

MIK Если можно написать оптимальный запрос

в рамках задачи нуфа - без временных будет быстрее, к гадалке не ходи

(80) завтра с вечером на 2 терабайтной базе поиграюсь с профайлером ))

(129) нафига профайлер? начни с ТЖ

Как я и говорил

0.374 с

ВЫБРАТЬ
Контрагенты.Ссылка,
Контрагенты.ИНН
ИЗ
Справочник.Контрагенты КАК Контрагенты
ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
Контрагенты.ИНН КАК ИНН
ИЗ
Справочник.Контрагенты КАК Контрагенты

СГРУППИРОВАТЬ ПО
Контрагенты.ИНН

ИМЕЮЩИЕ
КОЛИЧЕСТВО(Контрагенты.ИНН) > 1) КАК ВложенныйЗапрос
ПО Контрагенты.ИНН = ВложенныйЗапрос.ИНН

0.546 с

ВЫБРАТЬ
Контрагенты.ИНН КАК ИНН
ПОМЕСТИТЬ ВТ
ИЗ
Справочник.Контрагенты КАК Контрагенты

СГРУППИРОВАТЬ ПО
Контрагенты.ИНН

ИМЕЮЩИЕ
КОЛИЧЕСТВО(Контрагенты.ИНН) > 1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
Контрагенты.Ссылка,
Контрагенты.ИНН
ИЗ
Справочник.Контрагенты КАК Контрагенты
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ КАК ВТ
ПО Контрагенты.ИНН = ВТ.ИНН

(131) у тебя база кривая

(131) а все почему? у нас сервера бодрее

с 3мя контрагентами

(132) харе троллить

(131) Да, первый запрос наиболее оптимальный, имхо.

Почему все привязались к уникальности ИНН? Обособки уже отменили?