ковыряю тут запросы в 8

пусть есть два справочника Сотрудники (иерархический справочник) и подчинённый ему Дети

написать запросы :
1. получить всех сотрудников, имеющих детей
2. -||- без детей


1.

"ВЫБРАТЬ РАЗЛИЧНЫЕ
|    Дети.Владелец.Ссылка
|ИЗ
|    Справочник.Дети КАК Дети"


2.

"ВЫБРАТЬ
|    Сотрудник.Представление
|ИЗ
|    Справочник.Сотрудники КАК Сотрудник
|ГДЕ
|    (НЕ Сотрудник.Ссылка В
|                (ВЫБРАТЬ РАЗЛИЧНЫЕ
|                    Дети.Владелец.Ссылка
|                ИЗ
|                    Справочник.Дети КАК Дети))
|    И Сотрудник.ЭтоГруппа = ЛОЖЬ"

второй запрос

ВЫБРАТЬ
   Сотрудник.Представление
ИЗ
   Справочник.Сотрудники КАК Сотрудник
левое соединение Справочник.Дети КАК Дети по Сотрудник.ссылка = Дети.Владелец.Ссылка
где Дети.Ссылка есть null

(5) что так что так запрос обойдет 1000000 элементов.
Только вернет разное количество.

Что тебя смущает в этих запросах?

В запросах 1С не рекомендуется использовать конструкцию "В", потому что не всегда делаются оптимальные планы.

(9) при этом сами ее активно используют в шаблонах рлс

(10) Историю кто то выкладывал. Что то вроде "Типовые конфигурации 1С не имеют статуса совместимо с 1С"...

(6) ха, про "ЕСТЬ NULL" не знал, как пользоваться



"ВЫБРАТЬ
|    Сотрудник.Представление
|ИЗ
|    Справочник.Сотрудники КАК Сотрудник
|        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Дети КАК Дети
|        ПО Сотрудник.Ссылка = Дети.Владелец.Ссылка
|ГДЕ
|    Дети.Ссылка ЕСТЬ NULL
|    И Сотрудник.ЭтоГруппа = ЛОЖЬ"

(8) оптимальность интересует

мне кажется, что (6) не оптимально

он будет "клеить" всех сотров и все детей.владельцев

что-то типа того, но тут ошибка


ВЫБРАТЬ
   Сотрудник.Представление
ИЗ
   Справочник.Сотрудники КАК Сотрудник

ЛЕВОЕ СОЕДИНЕНИЕ
   (ВЫБРАТЬ РАЗЛИЧНЫЕ
       Дети.Владелец.Ссылка
   ИЗ
       Справочник.Дети КАК Дети) КАК СотрудникиСДетьми

ПО Сотрудник.Ссылка = СотрудникиСДетьми.Ссылка

ГДЕ Сотрудник.Ссылка ЕСТЬ NULL И Сотрудник.ЭтоГруппа = ЛОЖЬ

(15)

ВЫБРАТЬ
   Сотрудник.Представление
ИЗ
   Справочник.Сотрудники КАК Сотрудник
ЛЕВОЕ СОЕДИНЕНИЕ
   (ВЫБРАТЬ РАЗЛИЧНЫЕ
       Дети.Владелец.Ссылка как Ссылка
   ИЗ
       Справочник.Дети КАК Дети) КАК СотрудникиСДетьми
ПО Сотрудник.Ссылка = СотрудникиСДетьми.Ссылка
ГДЕ Сотрудник.Ссылка ЕСТЬ NULL И Сотрудник.ЭтоГруппа = ЛОЖЬ

Но по сути тоже самое что и (12)

1 и 2 можно получить одним запросом ;)

(16) ахтунг! Зачем соединять с вложенным запросом-то?

(0) В первом запросе убери точкаСсылка

+ к (18) да и во всех остальных тоже

заменить "Сотрудник.ЭтоГруппа = ЛОЖЬ" на "(НЕ Сотрудник.ЭтоГруппа)"

второй не оптимальный, надо левое соединение и отбор по null,

да и первый, если придираться - сгруппировать работает быстрее, чем РАЗЛИЧНЫЕ на больших выборках

(21) сгруппировать работает быстрее, чем РАЗЛИЧНЫЕ на больших выборках - врешь

(22) а почему?

(16) запрос не работаеот

(17) > ахтунг! Зачем соединять с вложенным запросом-то?

так это не быстрее ?

переправил (16) получил

"ВЫБРАТЬ
|    Сотрудник.Представление
|ИЗ
|    Справочник.Сотрудники КАК Сотрудник
|        ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
|            Дети.Владелец КАК Ссылка
|        ИЗ
|            Справочник.Дети КАК Дети) КАК СотрудникиСДетьми
|        ПО Сотрудник.Ссылка = СотрудникиСДетьми.Ссылка
|ГДЕ
|    СотрудникиСДетьми.Ссылка ЕСТЬ NULL
|    И (НЕ Сотрудник.ЭтоГруппа)"

(18) (19) ага

(20) почему ? это быстрее или как ?

(9) > В запросах 1С не рекомендуется использовать конструкцию "В", потому что не всегда делаются оптимальные планы.


где этот написано ?

(5) Запрос итак тебе обойдёт все элементы.. а потом уже из них выберет только различные..

(28) На ИТС вроде читал

(30) не путаешь с "В ИЕРАРХИИ"?

(31) В ИЕРАРХИИ не заменить соединением, а там было что вместо "В" лучше использовать соединение.

(25) это намного медленнее. Фирма 1С рекомендует избегать соединений с вложенными запросами и виртуальными таблицами (они тоже являются вложенными запросами, только формируются системой).

+(33) разумеется, не на каждый случай. Основная причина, по которой стоит отказываться с соединением с вложенными запросами - велик риск ошибки СУБД в построении плана запроса. И самое главное, нужно учитывать прогноз количества элементов, которые будут в соединяемых таблицах: если в обоих таблицах прогнозируется несколько десятков или сотен строк, то можно смело соединять, а если же хотя бы в одной таблице будут десятки тысяч строк, то тады лучше избегать таких соединений...

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

(33) какой тогда вариант ?

*оптимальный

(36) соединить таблицы

ПО Сотрудники.Ссылка = Дети.Владелец

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

(38) а если бы не в 1с это писать ?

У справочника-владельца есть индекс

[Ссылка]

у подчиненного справочника есть индексы

[Владелец]+[Код]+[Ссылка]

вот по этим индексам оно и соединится оптимально.

(39) я х. з. Зависит от СУБД.

(41) sql | mySQL ?

(40) тупо левое соединение владельца с дети.владелец и оттуда смотреть НУЛЛ?

(43) да!

(42) ну в рекомендациях как раз описано применительно к SQL Server.

(45) а где они эти рекомендации ?

(44) ладно

пусть владельцев 10 000
у каждого по 50 000 детей

всё равно такой же запрос писать ?

тута:

http://kb.1c.ru/articleView.jsp?id=44

(47) желательно. Если очень-очень хочется, то можно и через вложенный запрос, но может получиться не айс...

(48) что нужно для доступа ?

(50) очевидно, логин и пароль...

(51) ИТС подписки 7

(52) не-а. Отдельные, как на доступ в партнерскую конференцию. На диске ИТС есть то же самое:

Технологическая поддержка > Методическая поддержка 1С 8 > Технологические вопросы крупных внедрений > типичные причины неоптимальной работы запросов и методы оптимизации

И все на том же диске стоит почитать:

Технологическая поддержка > Методическая поддержка 1С 8 > Методические рекомендации по конфигурированию > Язык запросов

(54) что-то там про индексы нет

(55) про индексы отдельная статья.

http://kb.1c.ru/articleView.jsp?id=68

(56) почитаем =)

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

ещё вопрос :

на ИТС есть пример внутреннего соединения :

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


это будет тоже самое и с такой же скоростью выполняться, как

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

это вопрос как бы

результат тот же
а вот скорость как замерить

ЗАК... слушай.. а есть что-нибудь такое по типа СП только для языка запросов? Не поделишься?

(62) да хоть http://base.vingrad.ru/view/2871-Osnovyi-yazyika-SQL

(59) 1с сделает это одинаковым.

(63) Так это ж про SQL запросы.. а я про 1С спрашивал же :(

(59) В первом случае будет быстрее.

+(66) Во втором случае он сделает декартово произведение, а потом наложит учловие "ГДЕ".

(64) тогда зачем два варианта ?

(65) тоже самое

(66) обоснование
(67) внутренне соединение это что такое по-твоему ?
я всегда думал, что это декартовое произведение, а потом фильтр

(70) Внутреннее соединение - берутся все значения левого множества у которых есть соответствие из правого множества.

+(71)
Для декартова произведения не надо вообще писать ключевое слово "соединение". Просто в  "ИЗ" указываешь 2 таблицы через запятую и каждой строке левого множество будет соответствовать каждая строка правого множества.

+(72) В SQL есть CROSS JOIN.

(71) да, согласен


Внутренние соединения

Внутренние соединения - самый распространённый тип соединений. Внутреннее соединение просто находит пары строк, которые соединяются и удовлетворяют предикату соединения. Например, показанный ниже запрос использует предикат соединения "S.Cust_Id = C.Cust_Id", позволяющий найти все продажи и сведения о клиенте с одинаковыми значениями Cust_Id:

select * from Sales S inner join Customers C on S.Cust_Id = C.Cust_Id

нужно проверять на данных
надо в БД забить 1 000 000 детей

(75) что мешает?

"ВЫБРАТЬ РАЗЛИЧНЫЕ
|    Дети.Владелец
|ИЗ
|    Справочник.Дети КАК Дети"
самое оптимальное - так. будет проверяться 1 индекс и вывод его. без доп чтений.
а все остальное будет тормозом.
запрос "В" может свалится в "или" и будете иметь реальные тормоза.

(67) планы то сравнивал? чтобы такое говорить?

(21) различные и сгруппировать - монопенисуальные операции если план смотреть..

По 2рому запросу в данном случае наверное разницы нет так как объемы маленькие но в целом лучше использовать временную таблицу и пакет запроса.

1. Формируем ВТ:  ВТСотрудникиСДетьми, добавляем индекс по "ССылка".

2. К  "Справочник.Сотрудники" левым соединением присоединяем ВТСотрудникиСДетьми в где пишем условие ВТСотрудникиСДетьми.Ссылка ЕСТЬ NULL ну и другие по желанию.

(22) при выборке одного поля по индексу - да. иначе - нет

(33) "Это намного медленнее. Фирма 1С рекомендует избегать соединений с вложенными запросами и виртуальными таблицами (они тоже являются вложенными запросами, только формируются системой)".

Ну с Вложенными запросами понятно, на момент выполнения запроса SQL ничего не знает о количестве записей в результате вложенного запроса, и с индексами тоже нет определенности поэтому запрос может выполнятся не оптимально.

А в чем проблема при соединении с ВременымиТаблицами?

(0)
  Не совсем корректно поставлено вопрос, поскольку SQL - это декларативный язык, а не процедурный. Понятие эффективности лучше всего относить к плану исполнения запроса в применении к конкретным данным. Один и тот же текст запроса может транслироваться в план огромным числом способов в-зависимости от большого числа факторов. И наоборот - разные запросы могут порождать один и тот же план.

  Пример. Есть два запроса.

  Первый:

ВЫБРАТЬ Таб1.*
ИЗ Таб1 ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб2 ПО Таб1.Поле = Таб2.Поле

Второй:

ВЫБРАТЬ Таб1.*
ИЗ Таб1
ГДЕ Таб1.Поле В (ВЫБРАТЬ Таб2.Поле ИЗ Таб2)

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

Первый.

   ВЫБРАТЬ РАЗЛИЧНЫЕ
       Владелец
   ИЗ
       Дети

Второй.

   ВЫБРАТЬ РАЗЛИЧНЫЕ
       Сотрудники.Ссылка
   ИЗ
       Сотрудники
       ЛЕВОЕ СОЕДИНЕНИЕ Дети ПО Сотрудники.Ссылка = Дети.Владелец
   ГДЕ Дети.Владелец ЕСТЬ NULL

В общем, пробуем и смотрим план! :)

Кстати (17) тоже прав может быть в данном случае выгоднее будет сразу левым соединением без ВТ соединить, но если нужно одновременно получать эти данные то пакеты будут оптимальней.

+ (83) Во втором нужно, конечно, условие еще на группы поставить

(0) Кстати, первый запрос такой и предложен был, только .Ссылка надо убрать, иначе может быть лишнее неявное соединение :)

(81) планы в студию где "иначе нет"

(83) "  Вроде бы разные запросы, но на MS SQL план исполнения обоих у меня получался совершенно одинаков. Не похож, а именно совершенно одинаков. Поэтому, что бы узнать точно, что будет эффективнее - путь только один. Пробовать на конкретных данных и анализировать план исполнения. "
повезло.

(83) Я вообще не понимаю зачем использовать конструкцию В (Выбрать .... ) всегда надо в этом случае делать внутренее соединение.

Не В(Выбрать ) я ещё могу понять.

(89) отбор в параметрах виртуальной таблицы

(89) ты не умеешь их готовить.

(87) очень просто:
берешь
Выбрать * Из Справочник.Номенклатура, открываешь конструктором, удаляешь поле Ссылка (ну и ТЧ, если есть). 1 вариант - получившегося запроса меряешь с Различные, другой - с Группировать.
У меня получилось с Различные 2.2 секунды, с Группировать - 0.2 на 10к элементов справочника номенклатуры

(92) а второй раз с Различные?

(77) согласен, даже в таблицу не полезет

(93) после нескольких выполнений картина более-менее выровнялась, но все равно:
Название таблицы    Время подзапроса    Количество строк
РАЗЛИЧНЫЕ1    0,5    10 080
СГРУППИРОВАТЬ1    0,485    10 080
РАЗЛИЧНЫЕ2    0,547    10 080
СГРУППИРОВАТЬ2    0,328    10 080

разница, очевидно, в пользу Сгруппировать

более того, даже если тупо выбирать .Ссылка - все равно ~15% в пользу Сгруппировать

(97) не везет твоим различным что могу сказать. у меня в обратку чаще. сгруппировать дольше чем различные..

(98)+в общем я сравнивал планы. они идентичны. поэтому время зависит от загрузки сервака и прочее прочее

100!   =)

черт((

(101) шо таки?

нда, у меня таки тенденция:


ВЫБРАТЬ
   Таблица.Дата
ПОМЕСТИТЬ Сгруппировать1
ИЗ
   Документ.РеализацияТоваров КАК Таблица

СГРУППИРОВАТЬ ПО
   Таблица.Дата
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗЛИЧНЫЕ
   Таблица.Дата
ПОМЕСТИТЬ Различные1
ИЗ
   Документ.РеализацияТоваров КАК Таблица
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗЛИЧНЫЕ
   Таблица.Дата
ПОМЕСТИТЬ Различные2
ИЗ
   Документ.РеализацияТоваров КАК Таблица
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   Таблица.Дата
ПОМЕСТИТЬ Сгруппировать2
ИЗ
   Документ.РеализацияТоваров КАК Таблица

СГРУППИРОВАТЬ ПО
   Таблица.Дата


получает
Название таблицы    Время подзапроса    Количество строк
СГРУППИРОВАТЬ1    10,797    1 409 449
РАЗЛИЧНЫЕ1    10,921    1 409 449
РАЗЛИЧНЫЕ2    11,358    1 409 449
СГРУППИРОВАТЬ2    10,948    1 409 449

хоть чуть-чуть, но сгруппировать быстрее :)

условие можно написать так (НЕ Сотрудник.ЭтоГруппа) - впрочем это дело вкуса.