Господа, то что 1С в виртуальных таблицах использует отдельные отборы в параметрах виртуальной таблицы и в условии ГДЕ - это благо или маразм?

Дело в том, что по сути, она перекладывает на программиста то, с чем легко может справиться компилятор средней руки и усложняет язык запросов. Чем ей не нравится классические условия в ГДЕ?
Неужели по условиям в ГДЕ нельзя автоматом определить, какие ограничения накладываются на виртуальную таблицу!?

А вы как считаете?

Книга знаний: Виртуальные таблицы запросов

ап

(0) тебе скучно ?
или я не понял вопрос?
как ты предлагаешь объединить фильтр и условие? как в 7.7?

+(3) а если мне для периодического РС, нужно именно условие "ГДЕ" , а не фильтр ... как твой "компилятор средней руки" это отработает?

Вместо:
ИЗ Регистр.Обороты(&ДатаНач, &ДатаКон, КОнтрагент=&Контрагент)

Использовать классику:
ИЗ Регистр.Обороты()
ГДЕ Дата Между &ДатаНач И &ДатаКон И КОнтрагент=&Контрагент

Ибо компьютер может сам оптимизировать запрос, нафига эти извращения?

(5) ты серьезно считаешь что эти 2 запроса, во всех случаях вернут одно и тоже?

//первый запрос
ВЫБРАТЬ
   МестонахождениеОСБухгалтерскийУчетСрезПоследних.ОсновноеСредство КАК ОсновноеСредство,
ИЗ
   РегистрСведений.МестонахождениеОСБухгалтерскийУчет.СрезПоследних(&ДатаОстатков,    Организация = &Организация И  МОЛ = &МОЛ И Местонахождение = &Подразделение) КАК МестонахождениеОСБухгалтерскийУчетСрезПоследних

//второй запрос  
ВЫБРАТЬ
   МестонахождениеОСБухгалтерскийУчетСрезПоследних.ОсновноеСредство КАК ОсновноеСредство,
ИЗ
   РегистрСведений.МестонахождениеОСБухгалтерскийУчет.СрезПоследних(&ДатаОстатков,    ) КАК МестонахождениеОСБухгалтерскийУчетСрезПоследних
ГДЕ     Организация = &Организация И МОЛ = &МОЛ И Местонахождение = &Подразделение


(6) Терв, ты тупишь, речь шла об оборотах...
В примере остатков дату среза можно оставить в виртуальных таблицах, но фильтры нужно выносить за ГДЕ, смысл в этих издевательствах над SQL?

Вариант 2. В отношении ветки.

Для справки: при переводе запроса на скл, виртуальная таблица преобразуется в подзапрос.
Отбор в виртуальной таблице будет условием ВНУТРИ подзапроса.
Если применять ГДЕ, то условие будет снаружи подзапроса.
Вот и весь смысл - производительность

(8) это то он знает ... насколько я понимаю он предлагает компилятору автоматически определять куда лучше засунуть в фильтр или в условие.... вот только непойму нафига нужно это извращение...

(7) о каких издевательствах над SQL ты говоришь?

(8) Я в курсе.
(9) Терв правильно говорит - компилятор сам может понять, где выполнять запрос.
(10) Виртуальная таблица - это издевательство, на плечи кодера перекладывают то, что должен делать оптимизатор запроса.

(5) Чушь, на самом деле в твоем случае осьминожка семерит т.е. вернет тебе всю таблицу и только потом наложит условия, да и для регистров остатков в таком случае никакой оптимизации не будет

мое мнение, что как реализовала 1с более читабельно, тоесть мы заранее знаем где будет условие, а супер оптимизаторы - это фантастика...

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

(11) твои утверждения про виртуальные таблицы смелы конечно, но также абсурдны.

(11) боюсь если доверить это дело компилятору, то станет непредсказуем результат ... иногда нужно одно, а иногда другое.

(10) одна фраза ХДЕ - уже само по себе издевательство :)))

(9) нет, ну теоретически, наверное, это реализуемо
только я вспомнил свой запрос, где виртуальных таблиц больше 10 ка
представил, что будет в ГДЕ
неудобно. нагляднее когда в таблице отбор прописан.

Просто в некоторых случаях мне нужно кокретно указать куда это условие нужно засунуть. Например при запросе к регистру сведений. Компьютер может быть со мной не согласен :)

(18) +1, это я и имел ввиду в (6)

(15) а с учетом того, что 90 % писателей пользуются всякими построителями-сочинителями так вообще будет неясно не зги... кста, а може именно для построителей?!

(17) Если речь о твоем извращенном удобсвте, используй вложенный запрос.
А в большинстве случаев распределение запросов на фильтры вирт.таблиц и условие запроса только усложняет понимание.

(18) приведи контрпример, гыгыгы...

(20) читай (21)

(11) а есть ли уверенность, что запрос будет оптимизирован?

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

Просто и логично, долой извращения.

(22) см. (6)

(24) читай (25). Приведи контрпример

(23) как (20) коррелируется с (21)?

(27) пля, оптимизируй мне по твоему запрос, есть измерения Организация,Мол,Местонахождение

"ВЫБРАТЬ
   МестонахождениеОСБухгалтерскийУчетСрезПоследних.ОсновноеСредство КАК ОсновноеСредство,
ИЗ
   РегистрСведений.МестонахождениеОСБухгалтерскийУчет.СрезПоследних(&ДатаОстатков,    ) КАК МестонахождениеОСБухгалтерскийУчетСрезПоследних
ГДЕ     Организация = &Организация И МОЛ = &МОЛ И Местонахождение = &Подразделение
"

(27) ущу раз спрошу - ты уверен в том, что переданный тобой серверу запрос будет оптимизирован на сервере?

+30 еще раз...

(20) да вряд ли, щас тоже можешь ГДЕ взять в фигурные скобки, тот же результат
(21) речь о том, что ты опять занимаешься брейнфакингом.
сделала бы 1С так как ты щас хочешь, ты б написал, что маразм, надо отборы делать.

(26) и че, разве запросы вернут разные данные? Поясни, а то я че-то не догоняю...

(30) Оптимизировать может компилятор, до перевода в SQL

еще раз спрошу:

КАК определить куда ставить условие если виртуальная таблица имеет СОЕДИНЕНИЕ!!!!

(32) Не скажи, исчез бы лишний труд по поводу того, чтобы думать, что в фильтры ставить, что в отборы.

(35) пример

Есть переодический регистр сведений Работники. В нем Измерение Работник, Ресурс Состояние. Принимется/увольнятся один работник может много раз.

1) Нужно узнать всех уволенных на данный момент работников
2) Нужно узнать когда каждый работник был последний раз уволен

Никаких вложенных запросов не нужно ... Достаточно условий :)

(33) если ОС было принято в организацию, в определенное подразделение, определенному МОЛ, но было перещено (т.е. в срезе последних его не будет) ... если поставить фильтр .. то в результат оно попадет... а не должно ...

ЗЫ. это ошибка из типовой БП, не знай подправили или нет.

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

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

(29) Гыгыгы, легко...

ВЫБРАТЬ
   МестонахождениеОСБухгалтерскийУчетСрезПоследних.ОсновноеСредство КАК ОсновноеСредство,
ИЗ
   РегистрСведений.МестонахождениеОСБухгалтерскийУчет.СрезПоследних(&ДатаОстатков,    ) КАК МестонахождениеОСБухгалтерскийУчетСрезПоследних

ГДЕ     МестонахождениеОСБухгалтерскийУчетСрезПоследних.Поля.Организация = &Организация И МестонахождениеОСБухгалтерскийУчетСрезПоследних.Поля.МОЛ = &МОЛ И МестонахождениеОСБухгалтерскийУчетСрезПоследних.Поля.Местонахождение = &Подразделение ИЛИ МестонахождениеОСБухгалтерскийУчетСрезПоследних.Подразделение=&Подразделение2


Вкурил, или разжевать?

(41) можно подробнее что есть "гнездовое лупление"

(41) это потому что вместо классического WHERE используется уродство вроде фильтра вирт. таблиц.

Ах да, забыл проголосовать!

Как мы уже поняли эта оптимизация применима только для оборотов и остатков, для среза последних она вредна. Получается отсутствие стандарта. Либо параметры виртуальных таблиц есть и есть они для всех таблиц, либо их нет.

(45) для среза тоже катит

(40)

ВЫБРАТЬ
   ЗаключенныеДоговораОбороты.СуммаОборот,
   ЗаключенныеДоговораОбороты.Договор,
   ГрафикиПлатежейОбороты.СуммаОборот КАК СуммаОборот1
ИЗ
   РегистрНакопления.ЗаключенныеДоговора.Обороты(, , , Договор = &Договор) КАК ЗаключенныеДоговораОбороты
       ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ГрафикиПлатежей.Обороты(, , , Договор = &Договор) КАК ГрафикиПлатежейОбороты
       ПО ЗаключенныеДоговораОбороты.Помещение = ГрафикиПлатежейОбороты.Помещение


ну и как ты тут условие по договору реализуешь????

(42) ты не вкурил... с периодического РС ... фильтр и условие ГДЕ ... возвращают разный результат, при определенном наборе данных

(43) можно - Nested Loops

(0) хехе... какой-то Гений не гинеальный

(45) Например, если ты пишешь

Выбрать Курс из РегистрСведений.ИмяРек(&ДатаСреза) КАК Т
ГДЕ Т.Организация=&Организация

Ты подразумеваешь, что нужно получить срез последних и из результата выбрать те записи, где организация=Организация.

А если Выбрать Курс из РегистрСведений.ИмяРек(&ДатаСреза) КАК Т
ГДЕ Т.Поля.Организация=&Организация

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

ПРоблем не вижу.

ПРоблемы в мозгах разработчиков 1це.

(49) а по Русски можно? почему ты не рекомендуеш использовать вирт. таблицы в подзапросах?

(48) я то вкурил, читай (51)

(50) Какой то лексус подозрительно дешевый

ВЫБРАТЬ
   ЗаключенныеДоговораОбороты.СуммаОборот,
   ЗаключенныеДоговораОбороты.Договор,
   ГрафикиПлатежейОбороты.СуммаОборот КАК СуммаОборот1
ИЗ
   РегистрНакопления.ЗаключенныеДоговора.Обороты(, , , ) КАК ЗаключенныеДоговораОбороты
       ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ГрафикиПлатежей.Обороты(, , , ) КАК ГрафикиПлатежейОбороты
       ПО ЗаключенныеДоговораОбороты.Помещение = ГрафикиПлатежейОбороты.Помещение

ГДЕ ЗаключенныеДоговораОбороты.Договор = &Договор И ГрафикиПлатежейОбороты.Договор = &Договор


Какие проблемы?

ну что, контрпример будет?

(51) пля ... так и пиши мне не нравиться желтый цвет в "1С", давай те поменяем на "генитальный" ....
разница в чем? между фильтрами и твоими полями?
одна х-ня

(57)+1 :) И так и так придется указывать как фильтровать

(57) дык в том, что в моих где не нужно думать о производительности и не нужно думать, какие можно включать поля в фильтр, а какие нет. Да и к классическому SQL ближе.

(58) читай (59)
Суть в том, что 1С заставляет кодера думать там, где и так все ясно...

и еще выдает это за прогресс, гыгыгы....
И на экзаменах по спецам спрашивает... мда...

(52) а че ж нельзя то. можно и по-русски.
при большом количестве вложений скл сервер может ступить и выбрать неоптимальный план запроса. Nested Loops это когда для каждой записи одной таблицы выполняется запрос из другой таблицы или запроса.
вместо того, что бы сделать слияние этих таблиц (в экстазе).
А поскольку виртуальная таблица при переводе в скл сама представляет подзапрос, то вложенность увеличивается.
Все это можно прочитать в Проф разработке.

(59) ага и получим аналог языка запросов как в 7.7, спасибо знаем,наелись....
ты вот допустим знаешь, как поставить фильтры на таблицы в "клюшках" ?

(60) Я от этих раздумий не сильно утруждаюсь :) Но, для варианта в (51)

(55) и ты хочешь сказать, что
ГДЕ ЗаключенныеДоговораОбороты.Договор = &Договор И ГрафикиПлатежейОбороты.Договор = &Договор

лучше?

конечно дело вкуса, но я не извращенец... мне не нравиться...

(46) Не катит. Нужно выбрать затраты у которых настроен способ распределения статьи затрат.
ВЫБРАТЬ
   НЗП.*
ИЗ
   РегистрНакопления.НезавершенноеПроизводство.Остатки КАК НЗП
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.СпособыРаспределенияСтатейЗатрат.СрезПоследних КАК СпособыРаспределенияСтатейЗатратСрезПоследних
       ПО НЗП.Подразделение = СпособыРаспределенияСтатейЗатратСрезПоследних.Подразделение
           И НЗП.СтатьяЗатрат = СпособыРаспределенияСтатейЗатратСрезПоследних.СтатьяЗатрат
ГДЕ
   СпособыРаспределенияСтатейЗатратСрезПоследних.НеРаспределять = ЛОЖЬ

В этом запросе будут записи, где на дату среза НеРаспределять = ЛОЖЬ. А теперь если оптимизатор засунет это условие в параметры вирт таблицы, то в срез последних попадут записи где на предыдущую дату галка стоит, а на текущую не стоит. Что недопустимо

(65) значит ты извращенец, ибо в варианте с ГДЕ не нужно думать, на что накладывать условие, и какие поля допустимы в вирт.таблице, какие нет.

+(66) Что-то я усложнил, обычного среза последних достаточно для понимания недопустимости таких "оптимизаций"

(66) покури (51), уже разжевывал!

Могу еще раз, персонально:

Вариант 1:

ВЫБРАТЬ
   НЗП.*
ИЗ
   РегистрНакопления.НезавершенноеПроизводство.Остатки КАК НЗП
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.СпособыРаспределенияСтатейЗатрат.СрезПоследних КАК СпособыРаспределенияСтатейЗатратСрезПоследних
       ПО НЗП.Подразделение = СпособыРаспределенияСтатейЗатратСрезПоследних.Подразделение
           И НЗП.СтатьяЗатрат = СпособыРаспределенияСтатейЗатратСрезПоследних.СтатьяЗатрат
ГДЕ
   СпособыРаспределенияСтатейЗатратСрезПоследних.НеРаспределять = ЛОЖЬ



Вариант 2:

ВЫБРАТЬ
   НЗП.*
ИЗ
   РегистрНакопления.НезавершенноеПроизводство.Остатки КАК НЗП
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.СпособыРаспределенияСтатейЗатрат.СрезПоследних КАК СпособыРаспределенияСтатейЗатратСрезПоследних
       ПО НЗП.Подразделение = СпособыРаспределенияСтатейЗатратСрезПоследних.Подразделение
           И НЗП.СтатьяЗатрат = СпособыРаспределенияСтатейЗатратСрезПоследних.СтатьяЗатрат
ГДЕ
   СпособыРаспределенияСтатейЗатратСрезПоследних.Поля.НеРаспределять = ЛОЖЬ

(68) Почитай (69), хватит тупить про регистр сведений.

По сути срез последних - это вложенный запрос, в условии ГДЕ можо использовать отбор по полям вложенного запроса.

ВЫБРАТЬ Х ИЗ (ВЫБРАТЬ Y ИЗ Б) КАК А ГДЕ Х=11 И Б.Y=12
ВЫБРАТЬ Х ИЗ (ВЫБРАТЬ Y ИЗ Б) КАК А ГДЕ Х=11 И А.Y=12

Так понятнее? Тот же регистр сведений, срез последних

а чем тебы построитель не устраивае? используй его везде и будет тебе счастье :)

(71) Суть именно в том что по логике задачи нельзя где переносить в этот "вложенный запрос"
Допустим у нас есть такие данные
период  реквизит Галка
01.01   1        +
01.02   2        -
01.03   3        +

Делаем выбрать реквизит из среза последних () где галка= "-". Получаем пусто. Но если засунуть условие в параметры получим 2.
Я хочу сам управлять моим условием, к тому же получаются разные результаты

(73) речь ваще не об этом.... Мне надо думать, например, когда можно использовать поле регистратор, а когда нет... Тупизна, одним словом.

(69) Что-тоя твоего объяснения не понял: там одинаковые варианты.
(72) И этих выражений я тоже не понимаю
Давай на примере в (74)

(74) блин, сколько надо разжевывать:

Выбрать Реквизит ИЗ Регистр.Имярек ГДЕ ИмяРек.Галка="-"

Получаем пусто.

Выбрать Реквизит  ИЗ Регистр.Имярек ГДЕ ИмяРек.Поля.Галка="-"

Получаем 2.


Еще вопросы, господа матросы?

Ватсон, помедитируй над (72).

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

(78) купи слона.

Чего-чего? добавляется слово ПОЛЯ? Это по этому полю оптимизатор должен понять что нужно засунуть условие в "вложенный запрос"?

+(80) Так где же здесь оптимизация, если ты сам говоришь что нужно наложить условие на вложенный запрос. По сути нет никакой разницы написать слово ПОЛЯ или поставить круглые скобки

Смотри пример (72), там для явного вложенного запроса написано...
Вместо поля можно юзать любое другое имя.

ПО сути Выбрать Х из Регистр.ИмяРек.СрезПоследних

аналог:

Выбрать Х из (ВЫБРАТЬ ..ИЗ СЛУЖРегистр.ИмяРек КАК Поля) КАК ИмяРек.СрезПоследних

Чуствуешь аналогию?

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

По сути я так понял, что 1Сники привыкли писать раком и все, что улучшает их жизнь, воспринимается в штыки, гыгыгы..... Свое болото родным кажется, гыгыгы...

(82) Да понятно, что СрезПоследних - это вложенный запрос
Я говорю о том что все начиналось с высказывания "Неужели по условиям в ГДЕ нельзя автоматом определить, какие ограничения накладываются на виртуальную таблицу!? "
А закончилось тем что нужно писать слово ПОЛЯ, чтобы компилятор перенес данное условие в "вложенный запрос"
Сами себе противоречите, батенька

(83) не знаю. это может поперву обжигаешься, а потом когда вникаешь в суть вещей проблем не возникает

(85)  он сейчас тебе на  (59) укажет

(87) придется ответить, что в некоторых случаях думать очень даже нужно

(88) зачем ему думать.. он же "Гений" ....
видно совсем фиксина спермотоксикоз замучил, с каждым днем, ветки все бредовей и бредовей становятся

(89) Ну ладно хватит и так уже 90 постов нафлудили

(89) не вкурил смысл? ну-ну...

(85) и что? По любому тебе не нужно думать над тем, какие поля допустимы в виртуальных таблицах, какие нет. Ты просто накладываешь общее условие ГДЕ, а компилятор сам раскидывает по вложенным таблицам.

Констатирую: Тупые 1Сники.

(92) бред - такими темпами появиться язык програмирования, а-ля:

void main(void){
  CreateNewGameAndRun();
  return 0;
}

(92)и самый тупой из них - это Гений 1С.

Гений 1С почему бы тебе не написать свою платформу, а то у тебе столько претензии.
Вообще на половина твоих вопросов все ответы в ИТС!

Окей.
Вот логические доводы в пользу моего решения:
1. Защита от дурака. Невозможно написать медленный запрос. Система по-любому оптимизирует его на этапе компиляции.
2. Точечность. Условие записывается только в одном месте.
3. Лаконичность. В виртуальные таблицы передаются только необходимые параметры, избавляемся от множества запятых, например в запросе к бухитогам сейчас отдельное условие для счета, для корсчета, и еще одно общее отдельное условие - это ли не маразм.
4. Полнота - обыгрываются все ситуации, в том числе со срезами регистров сведений и вложенными запросами.
5. Дополнительный функционал - из внешнего запроса можно управлять отбором во вложенном запросе.

А теперь ваши доводы, тупые 1Сники. ;-)

(92), (96) А что говорил Сергей Нуралиев на эту тему в 2004 году по форумам, когда 8-ка только разрабатывалась? Наверняка вопросы были.

не надо слишком часто константировать на тупых одинэсников.
для этого есть блондинки-одинэсницы

(97) слив засчитан

Сотка!

Велик и могуч T-SQL . Вот взяли в 1С8.* за конька конструкции типа  select А.* from (select * from B where .. and ...) A . Всеж на этом постороено. Надо просто это спокойно воспринимать.

(96) не особо силен пока в ядре 8ки но есть вопрос, а когда мы создаем виртуальную таблицу в запросе, с условиями, не ограничиваем ли мы тем самым её объём? Оперативная то память не резиновая, или запрос все равно перед исполнением будет оптимизирован, вне зависимости от того где прописаны условия в параметрах таблицы или на вкладке условия?

(0)мне не влом указать параметры виртуальной таблици... но в лом думать про какие то поля которые я должен выбрать чтобы компилятор понял что это надо поставить в качестве параметра виртуальной таблице...

(102) в том то и дело, что 1С работу по оптимизации (чисто механическую, без всякого ИИ) с плеч компилятора переложила на мозги программиста.

(103) клиника

(105) думай как хочешь, революционер :)

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

есть здесь специалисты t-sql? для написания запроса вы тоже конструктором пользуетесь? ))

(108) а почему бы и не юзать конструктор. Я умею и с конструктором и без.

Это новые понты - я пишу SQL без конструктора?

(110) Обезъянка, всё, что делают нормальные люди - это ПОНТЫ.
Не понты - это жрать манную кашку, изобретать ведрокат и пирамидальную память.

(108) прикинь до чего дошел прогресс!
не только запросы, можно и приложение целиком накликать.

(112) видимо он классик - пишет в нотпаде.

1. Защита от дурака. Невозможно написать медленный запрос. Система по-любому оптимизирует его на этапе компиляции - и ЭТО называет себя "программистом" ???

(114) действительно, зачем это в паскале и 1С контроль выхода индекса за границы массива сделан, наверное специально для тупых 1сников, гыгыгыы....

(114) идиот, суть программирования - не только писать машинные коды, а автоматизировать труд программиста. Если можно не думать, нужно не думать.