То ли на ночь глядя соображается туго, то ли я никогда этого до конца и не понимал... :))

Что-то мне подсказывает, что только в детальных записях :o)
Но так ли это на самом деле?

имхо, разницы ноль :)

Если, к примеру, есть два регистра накопления, один "СуммыПродаж", другой "СебестоимостьПродаж", то что логичнее, ОБЪЕДИНИТЬ или СОЕДИНЕНИЕ?

(2) А вот щас тебе (и мне заодно) Стас объяснит, что это не так :))

(+3) Меня не пинать, я не извращенец писать продажи в два регистра, это 1С так делает :o)
Да и вопрос не в том, нужно писать продажи в один или в два регистра, вопрос в сабже

соединение пытается сопоставить две записи, т.е. найти соответствие по определенным полям,
а объединение просто объединяет, без попытки поиска

Стыдно, товарищи.

Мне стыдно, но тем не менее вопрос :))

Пусть простейший пример, два регистра продаж, в каждом одно измерение Номенклатура, в первом ресурс Себестоимость, во втором ресурс СуммаПродажи.

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

Я не знаю, что ты подразумеваешь под "культурным и ожидаемым" результатом. В общем случае результаты запросов будут разными.

(0) не знаю, как в 8-ке, в чистом скуле так:
объединение (join) выбирает из двух наборов данных (НД) только совпадающие записи по выбранному ключевому полю, однако есть еще left join и right join - там объединение ведется таким образом, что за основу берется один из НД и в результирующий НД попадают все записи одного НД + совпавшие из другого.
что есть внешенее соединение в терминах 1С для меня, увы, загадка.

(9) То же самое. Только мы еще говорим про FULL OUTER JOIN

(8) Я подразумеваю то, что я получу все продажи и все себестоимости товара воедино

Давайте разговаривать в терминах SQL. Смысл дискуссии не изменится.

(11) Давай разговаривать запросами.

(10) ага, так и думал, что outer?
тогда первый описанный мною вариант - inner (ну чтоб совпадать в терминах)

(12) момент...

+13 вопрос в 1-м предложении опечатка

1-ЫЙ ЗАПРОС: СОЕДИНЕНИЕ

ВЫБРАТЬ
   СебестоимостьПродажОбороты.Номенклатура,
   СебестоимостьПродажОбороты.СебестоимостьОборот,
   СуммыПродажОбороты.СуммаПродажиОборот
ИЗ
   РегистрНакопления.СуммыПродаж.Обороты КАК СуммыПродажОбороты
       ПОЛНОЕ СОЕДИНЕНИЕ РегистрНакопления.СебестоимостьПродаж.Обороты КАК СебестоимостьПродажОбороты
       ПО СуммыПродажОбороты.Номенклатура = СебестоимостьПродажОбороты.Номенклатура
ИТОГИ
   СУММА(СебестоимостьОборот),
   СУММА(СуммаПродажиОборот)
ПО
   Номенклатура

Подозреваю, что следующий запрос покажет тот самый "культурный и ожидаемый результат":

ВЫБРАТЬ Номенклатура, СУММА(Продажи), СУММА(Себестоимость)
ИЗ
(ВЫБРАТЬ Номенклатура, Продажи, 0 КАК Себестоимость
ИЗ РегистрНакопления.Продажи
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ Номенклатура, 0, Себестоимость
ИЗ РегистрНакопления.Себестоимость
) КАК Вложенный
СГРУППИРОВАТЬ ПО Номенклатура

2-ОЙ ЗАПРОС: ОБЪЕДИНЕНИЕ

ВЫБРАТЬ
   СебестоимостьПродажОбороты.Номенклатура,
   СебестоимостьПродажОбороты.СебестоимостьОборот,
   0 КАК СуммаПродажОборот
ИЗ
   РегистрНакопления.СебестоимостьПродаж.Обороты КАК СебестоимостьПродажОбороты

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
   СуммыПродажОбороты.Номенклатура,
   0,
   СуммыПродажОбороты.СуммаПродажОборот
ИЗ
   РегистрНакопления.СуммыПродаж.Обороты КАК СуммыПродажОбороты
ИТОГИ
   СУММА(СебестоимостьОборот),
   СУММА(СуммаПродажОборот)
ПО
   Номенклатура

(17) А зачем в этом случае использовать вложенный запрос?

(19) и кто так регистры проектировал...
сорри, просто мысли вслух
(20) это видимо inner join

Для коллекции другой пример.
Когда проводится расходная накладная, нужно в одном запросе получить количество, подобранное в доке и остатки из регистра накопления, что правильнее, объединение (с фильтром по номенклатуре в параметрах регистра накопления) или соединение?

(22) а операторов типа in там нету?

(21) Забей, это я привел упрощенный пример, такого в реальности нет.
Хотя в последней типовой УТ регистра продаж действительно два :o)

(22) Соединение

(23) Есть

+23 ну т.е. тра-ля-ля... номенклатура типа in (select from табличная часть) бла-бла...

(27) Есть, В, В СПИСКЕ, В ИЕРАРХИИ

(25) А почему здесь соединение, а в первом случае объединение? :))

Прав ли я в (1)?

(30) В общем, да. Речь именно о детальных записях

(28) дык может так и лучше? ну чем объединять, хотя не знаю как 1С себя при этом ведет, там видимо язык запросов писАли по принципу "абы не как у всех", SQL'92 им не писан, блин...
(29) наверное в 1-м случае inner, а во втором right join (если "правая" - это табл. часть дока)

(32) Ну откуда такие выводы? Его писали именно по SQL 92

Кстати, объединение просто добавляет только в случае ОБЪЕДИНИТЬ ВСЕ, иначе делается попытка соединить записи в одну ;)

(33) та возмушаюсь, что снова язык и логику собственную коверкать :(
(34) это ты что сейчас сказал? правда не понял...

(34) Такое поведение прописано в стандарте на UNION. Так и должно быть. В твоем случае такое поведение нужно обязательно отключить

(35) Никто ничего не коверкал, ни язык, ни логику. В чем проблема-то? Ты не знаешь SQL?

Мда, в общем-то, получается, я не вижу смысла вообще использовать полное соединение, так как его всегда можно заменить объединением, да еще при том не париться с проблемой, из какого регистра брать то или иное поле :o)

я вами горжусь, и как вы отличаете в этих текстах одно от другого...

(38) Полное соединение и объединение не взаимозаменяемые. Их результаты иногда совпадают, но это частные случаи.

(39) внешнее соединение = outer join или просто join
левое/правое внешнее соединение = left/right join
объединение = union
что тут непонятного?

(41) а это: КАК Вложенный в (18) что означало?

(35) Я имею в виду, что в случае ОБЪЕДИНИТЬ ВСЕ записи не пытаются соединиться в одну с агрегацией по агрегируемым полям, а в случае ОБЪЕДИНИТЬ пытаются.
То есть, если у меня есть по одной записи в регистрах продаж тапочек, то
1. При ОБЪЕДИНИТЬ ВСЕ будет две детальных записи
  Тапочки 10 (себестоимость)
  Тапочки 20 (сумма продажи)
2. При ОБЪЕДИНИТЬ будет одна запись
  Тапочки 10 (себестоимость) 20 (сумма продажи)

Вроде так :o)

+42 ой, понял, видимо вложенный select в 8-ке пишут почему-то после текста запроса
мама, роди меня обратно...

(41) Все непонятно :))
Приведи пример (как можно более простой), когда результат будет разным

(44) Что-то я не понял твоего веселья. Что тебя рассмешило?

(45) Нечисловые поля

(46) ну во вложенном запросе select сразу пишут, потом что выбирать, потом откуда, потом как (условия), здесь как бы наоборот: уточняем вложенность уже после текста... я не веселюсь, я понимаю что мне на ЭТОМ скоро писАть и я правда в шоке
похоже надо мануал типа запрос на традиционном сиквеле и рядом такой же на v8, чтоб выучить тупо...

(47) А пример где? :o)

+48 мне там еще много неясно, т.е. ясно, но не могу понять почему так вывернуто
впрочем это оффтопик, сорри

(48) Здесь тоже сразу пишут, а вложенность сразу определяется символом (

(51) а уточнение нафиг, оно ничего не означает? ("как вложенный")

(52) Это альяс, а не уточнение :D

Можно было написать КАК Агент007 или КАК ЗдесьБылВася

Просто вложенных запросов может быть вагон, надо же их как-то различать :o)

(52) Это всего лишь псевдоним вложенного запроса. Он обязателен.

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

insider

я правда не въеду нафига он, т.е. правило есть правило, но сбивает с толку, альясы у таблиц или значений каких-нить - это ладно, но вложенные запросы нафиг называть?
(57) все, больше не вношу смуту, беру ЖКК или какие они там теперь и молча читаю :)

(59) Они так и называются - ЖКК. У страха глаза велики.

(59) А как ты будешь обращаться к этому вложенному запросу, поля из него брать?
Альяс ему нужен затем же, зачем и таблицам - источникам, для идентификации

Так пример к (47) будет? ;)

(62) Придумай его себе сам. Поработай, например, с ценами или скидками контрагентов.

(60) ну это ясно, что выучить и понять нормальный программер может много, там с 8-кой еще много моментов из-за которых тормозится обучение: неоправданая цена, сложности с продажей (куча сертификатов и т.п.), перегруженность конф и их требования к ресурсам (снова неоправданные), нет прямых запросов и быстродействие не очень, слишком большой объем баз (как следствие), да много чего.
мне же зарабатывать, а не мучаться хочется, а пока имхо нерентабельно...
(61) мне не нужен вложенный запрос и поля его даром не нужны, мне результирующий НД нужен, что и получаю с помощью запроса

Ну скажи что-нить простенькое, с оджним измерением и одним ресурсом.
Можно бессмысленное с точки зрения экономики и вселенского разума :))

(64) В смысле неоправдано нИзкая цена, ты не готов работать с таким дешевым продуктом? :))

А как ты в результирующем запросе будешь обращаться ко вложенному?

(67) Это к (64)

(65) Измерение Номенклатура, регистр Цены и регистр СкидкиПоНоменклатуре. Эту информацию можно получить только соединением (join). При UNION придется использовать извраты типа MAX, но это не гарантирует правильность результата, особенно при двух измерениях (допустим, еще ХарактеристикаНоменклатуры). И без вложенного запроса все равно не обойтись

(66) ну бухия дороже, а толку? а про УПП я не говорю, уж лучше написАть самому, а не пытаться внедрять монструозное детище программеров 1С, не только же мое мнение, я не один так думаю :)
(67) скажи честно, зачем? :)

(70) Ты не поверишь, сколько много людей думают, что лучше внедрять типовые конфигурации и дописывать их при необходимости.

(70) Ну, здесь примерно такая схема

SELECT
Поле1 из вложенного запроса с именем ?
Поле2 из вложенного запроса с именем ?
ИЗ
(Вложенный запрос без имени), (Вложенный запрос без имени)

(72) странно это как-то, почему такая выборка? т.е. логику не понимаю :(
ну нельзя получить в результате комбинации запросов, джойнов и т.п. ОДНУ таблицу в виде результата с полями, которые нужны?

(69) Все-равно не понял :o)
А можно пример на пару - тройку записей в каждом регистре

(71) Я тоже так думаю :))

(70) поверю, знаю что много, но ко мне не за этим приходят :)
эх, не мой рынок...

(73) Так вот и получается, что у меня есть ДВА вложенных запроса, из которых я выбираю поля, спрашивается, если поле Поле1 есть в обоих запросах, то как определить, откуда брать?

Мда, еще немного и мы сделаем ветку "интересной" :))

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

(78) ну могу помолчать, мне кажется, что вопросами наводящими вынуждаю более наглядно показать, может еще кто почитает :)

(79) Я имел в виду, что она будет длиннее 100 постов ;)

(79) "сначала пишешь тексты запросов, а потом уточняешь как бы их взаимодействие"
Это или гениальная фраза, по которой видно глубину мысли, или наоборот, фраза полного чайника.

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

(81) Так мона пример по паре записей из кажого регистра? :))

(81) так я и есть чайник, я не понимаю логику просто, будь снисходительнее :)
ага, примеры рулят, а то у меня каша в голове...

(+83) А то уж больно хочется уцепить суть, а пока что-то все вокруг да около :o)

Я уже дал вам пример. PR, запускаешь консоль запросов и проверяешь

Всем спать...

(87) Присоединяюсь к мнению.

(87,88) у нас с вами час разница, так что рано еще :)

(86) Вот ведь добрый какой :o)
Хорошо, если гора не идет к Магомету... :))

Не хочешь ли ты сказать, уважаемый, что данная ситуация отработается по разному при использовании соединения и объединения?

Записи регистра Цены
1. Тапочки 100
2. Вентилятор 200

Записи регистра СкидкиПоНоменклатуре
1. Тапочки 10%
2. Вентилятор 20%

(87) Не мешай увеличивать архив МиСты :))

(90) Добавь еще измерения Тип цен и Тип скидки для разнообразия.

(92) OK :))

Записи регистра Цены
1. Тапочки      ПродажнаяЦена    100
2. Вентилятор   ЗакупочнаяЦена   200

Записи регистра СкидкиПоНоменклатуре
1. Тапочки      РозничнаяСкидка  10%
2. Вентилятор   ОптоваяСкидка    20%

Разницы не вижу, поскольку в обоих случаях будет две записи :))
Вроде как //тихо в сторону :o)

PR, да меня кстати дошло причем псевдонимы, просто в сиквеле это юзают, если нужны группировки по результирующим полям сложного запроса (с объединениями напр.) с групировками, причем по другим полям или с вычислением доп. аггр. величин.
Выходит, что в (79) все было верно :)
(93) имхо что так, что этак сольет все в один... вот только с нечисловыми полями траблы, уточни задачу, точнее пример :)

(95) Где траблы-то, нечисловые поля легко "складываются" с NULL в другом запросе :))

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

(97) Разве в классическом (а не нормальном :)) ) сиквеле нельзя "складывать" поля с NULL?

(98) к словам цепляешься, уел, буду корректней в формулировках :)
можно конечно, я там скорее об алиасах писАл, о том, что каждый раз имеем дело с объединенным НД, который не требует уточнения составляющих, т.к. подзапрос уже выполнен и его имя нас не волнует.

100

(100) ну вот, дождался, ветка стала интересной :)
впрочем мы уж давно отклонились в чисто теоретическую плоскость

(99) А записи из этого подзапроса нас волнуют?
Я не имею в виду подзапрос, который используется в условии (то есть в in)

допустим мы выбираем из совокупности двух запросов, которые получены с помощью union, так нам не важно как каждый из этих двух назывался, просто даем псевдоним результату их выполнения (т.е. уже объединенному НД) и выбираем из него.
пример можно привести, но он из 77 и без dds общаться будет сложно, а комменты я замучаюсь писать

(103) А если у нас join?

(104) join вообще не так пишется, т.е. там нет прямого select, т.е. и запроса как такогового нет
ну если можешь очень абстрактно подойти, могу запостить пример, чтоб не "на пальцах"

Ситуация очень простая, есть два вложенных запроса, соединеных join'ом, которые выступают в роли источника записей

+105 что-то типа выборки остатков, нечитаемо немного, но самое маленькое, что нашел:

   ДатаОст=Формат(НачМесяца(ДобавитьМесяц(ПолучитьДатуТА(),-1)),"ДГГГГММДД");
Дата1  =Формат(НачМесяца(ПолучитьДатуТА()),"ДГГГГММДД");
Дата2  =Формат(ПолучитьДатуТА(),"ДГГГГММДД");
   
Query=CreateObject("ODBCRecordSet");
ТекстЗапроса="--
|select code, sum(NOst1)+sum(Prih1)-sum(Rash1) as NOSER,
|   sum(NOst2)+sum(Prih2)-sum(Rash2) as SERIE
|from (
|select rtrim(s.code) as code,
|    (case when d.sp337=0 then sum(r.sp168) else 0 end) as NOst1, 0 as Prih1, 0 as Rash1,
|    (case when d.sp337=1 then sum(r.sp168) else 0 end) as NOst2, 0 as Prih2, 0 as Rash2
|from rg165 r inner join dh67 d on r.sp169=d.iddoc, sc36 s
|where convert(datetime,r.period)=convert(datetime,'"+ДатаОст+"')
|          and s.id=r.sp167
|group by s.code, d.sp337
|
|union all
|
|select rtrim(s.code) as code,
|    0 as NOst1,
|    (case when (d.sp337=0)and(r.debkred=0) then sum(r.sp168) else 0 end) as Rrih1,
|    (case when (d.sp337=0)and(r.debkred=1) then sum(r.sp168) else 0 end) as Rash1,
|    0 as NOst2,
|    (case when (d.sp337=1)and(r.debkred=0) then sum(r.sp168) else 0 end) as Prih2,
|    (case when (d.sp337=1)and(r.debkred=1) then sum(r.sp168) else 0 end) as Rash2
|from ra165 r inner join dh67 d on r.sp169=d.iddoc inner join _1sjourn j on r.iddoc=j.iddoc, sc36 s
|where left(j.date_time_iddoc,8) between convert(datetime,'"+Дата1+"') and convert(datetime,'"+Дата2+"')
|          and s.id=r.sp167
|group by s.code,d.sp337, r.debkred
|
|) tmp
|group by tmp.code
|";


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

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

+107 я мог и не писАть вообще псевдоним к результирующему НД, скорее для удобочитаемости, чем из требований синтаксиса

(108) форма записи какая-то другая там, вот и получается, что не понимаем друг друга... или только я один не понимаю...

Мне вот какая мысль пришла в голову, при использовании соединения я могу управлять полями, по которым хочу соединять записи из двух таблиц, а при объединении нет.
Собственно, пожалуй это единственный случай, очень редкий впрочем, когда нужно использовать соединение.
То есть примерно так: хочу записи из двух таблиц при совпадении поля номенклатура соединить, а при совпадении поля склад не соединять, а оставить две записи

(11) при join ты ОБЯЗАН указать общее поле, при union типы и кол-во полей должны сходится - это немного разные вещи

(107) Так у тебя union, а я говорю про join :))

(113) ты там join не увидел?! да их там хватает...

+114 отож, у вас у джойна какой-то странный смысл и написание и вовсе не по стандарту имхо

(112) Да, но при соединении я могу соединять, к примеру, по номенклатуре и складу, а могу только по номенклатуре.
При объединении получается соединение записей сразу и по номенклатуре и по складу

(114) Там, если я правильно рассмотрел, вложенный запрос получается один, а не два ;)

(+117) А поэтому неоднозначности в источнике не возникает и альяс не обязателен :))

(116) ну все верно
(117) вложенный запрос состоит из объединенных (union) двух, в каждом из которых куча соединений (join) и case чего в эске наверное и вовсе нету...

(115) Что именно в join_v8 не по стандарту?
(119) case есть в 1С 8.0

(118) в классическом sql я не смогу привести пример "неоднозначности" источника, ибо язык этого не предполагает
(120) ну видишь, что мы с PR как будто на разных языках говорим, рассуди или объясни
насчет case - это гут

insider, я предлагаю тебе не поливать 8.0 грязью.
если ты не знаешь возможностей 8.0, то этого не значит, что 1С чего-то не умеет или чему-то не соответствует. Лучше задавай вопросы, читай ЖКК, не забывай почаще добавлять ИМХО.

Рому вообще бывает иногда очень сложно понять. Но легче, чем Гения 1С.

(119) Есть, почему нет
Главное, что после выполнения вложенного запроса получается ОДИН, а не ДВА вложенных запроса :o)
А ты попробуй сделать ДВА вложенных запроса в качестве источников данных, соединеных join'ом

(121) Еще как предполагает :))

(122) грязи никакой не было, я с PR читсто теоретический вопрос обсуждал, про case написал "наверное" (что вроде типа имхо, но это не имхо, т.к. я не знал об этом, а мог лишь предполагать)
в 8-ке попытались сделать адекватный язык запросов - это верно, но почему не обсудить детали? мне нет выгоды от "поливания", и объяснить свое незнание v8 я таким образом не пытаюсь
(123) с Гением не сталкивался как-то... не помню
(124) не могу :) или не понимаю что ты хочешь или в сиквеле так нельзя :)

(126) Скажу офигенную для тебя мысль: язык запросов 1С 8.0 в некоторых момент ПРЕВОСХОДИТ стандартный SQL. Ты поражен?

(126) Я хочу примерно следующее (уж не знаю, можно ли):

ВЫБРАТЬ
  ВложЗапрос1.Поле1
  ВложЗапрос2.Поле2
ИЗ
(ВложЗапрос1)
join
(ВложЗапрос2)

Понятно?

(127) ну рад скорее :) просто непривычность записи и кажущиеся необычными трактовки сбивают с толку.
P.S. заметь, а до сих пор нифига не ясно, что за такие два набора данных имеет ввиду PR - вот и не знаю, это фича или баг языка или такого и вовсе нет...
(128) принцип матрешки, такая запись как у тебя мне непонятна, точнее я ТОЧНЫЙ эквивалент не могу привести, так не получится, все равно сначала join, потом выборка

(129) Да две таблицы просто :))

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

(+129) Вооо! Вот про это я и говорю, в классическом SQL наглядность теряется, а здесь я вижу КРАСИВО :)))

(132) а, ну ладно, мне там как-то удобнее, да и набирать меньше.
имхо :)

(131) Да не надо, при таком подходе конечно не будет неоднозначности :))
Пример простой: таблица остатков товаров и таблица резервов товаров

(133) Там читабельность хуже. IMHO :)))

(135) Достаточно бредовое замечание, тебе не кажется?

(134) ну вот сверху у меня усложненный вариант, там идет выборка из таблицы остатков и движений, проверяется на определенное поле документа, который является измерением регистра (чтобы разделить остатки по "типам", надо так было), ну и сравнение с позицией ТА, ну это уже тривиально
(135) спорно :) но о вкусах спорить не имеет смысла, так что...

+137 плюс джойн с журналом доков, т.к. только там лежит позиция документа

(136) Почему? Мне вот например очень важна читабельность запросов :o)
А текст запросов на восьмерке и классическом сиквеле различается, логично?

(137) в 8.0 нет ТА

(139) Они практически не различаются.

(141) Ключевое слово практически, не так ли? ;)

(142) Это "практически" не связано с читабельностью.

Хотя не спорю, свои пять копеек вносит русский синтаксис ;)

(140) в 7.7 на прямых запросах, даже если ТА временно перенесена назад ее тоже нет :)
(141) разве что сравнить с примером... т.е. как бы логично, что вроде все похоже и отличиям взяться неоткула, особенно если латиницей писАть, но вот то, что пишет PR я не могу привинтить к логике сиквела...

Щас ветку до 200 догоним, а все почему, а все потому, что нет примера :))

(146) примеров было куча :)))

(147) Того, которого просил я, не было :))
И не было подтверждения или опровержения (94) ;)

(128) Это классическое умножение таблиц. Замени join на запятую

(146) А мне вот интересно, почему человеку постоянно нужны примеры? Вот сколько угодно дай ему теории, а без примера она непонятна. И достаточно одного примера, чтобы наступило то самое "ПОНЯЛ, ЭВРИКА". Т.е. у человека ИНДУКЦИЯ гораздо важнее ДЕДУКЦИИ. Ну это уже к Rovan'у...

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

(150) считаешь, что мышление в-основном строится по принципу от частных утверждений к общим? :)

(152) Я нахожу этому все больше и больше подтверждений. Даже дедукцию можно рассматривать, как обратную индукцию.

(150) Потому что думать всегда от общего к частному череп треснет :o)

(151) Так вот в том-то и дело, что нет примера, где результат будет РАЗНЫМ, везде получается одинаковым :o)

В качестве примера (заметьте, примера!) давайте напишем две статьи по языку запросов 8.0:
1. Первая - чисто теоретическая, без конкретных примеров
2. Вторая - чисто практическая, только примеры.

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

(153) интересная мысль, надо подумать.
(154) да смотря как посмотреть, наоборот как бы проще, но закомплексованность мышления получается, шаблоны сплошные, а если от частных к общим - вероятность неверного скоропостижного обощения...
(156) согласен... вот только учась на примерах хватаешь "обезьяний рефлекс" и мыслишь шаблоном, а код то в статье может быть и неоптимальным, мы же все ошибаемся? вот так и пойми что лучше...

+157 к убежденный практик все равно пришел к тому, что теория рулит, т.е. знать задачу глубоко теоретически - и практическая реализация выйдет интереснее, красивей и... необычнее, а наоборот: все заглянем в один справочник и спишем одну и ту же формулу, которую может какой-то ламер нацарапал и будем поколениями ехать по колее, когда вокруг столько простора...
/меня заносит, ладно, вс имхо конечно же/

Сначала человек обжигается об огонь, а потом уже делает вывод, что горячее может обжечь, а не сначала он читает инструкцию безопасности, в которой говорится, что горячее может обжечь, из чего он делает вывод, что в костер не нужно совать руки.
Опыт - явление частное, а поскольку опыт первичен, то понятно, что общее проистекает из частного. А вот после появдения общего выявляется необнаруженное в момент опытов частное :))

(159) хм... сначала человек прыгает с 14-го этажа и пораскинув мозги понимает, что черепушка не выдержит такого экстрима :))
учатся на своих ошибках далеко не все, уж лучше на чужих :)

(160) Да, но чужие ошибки были первей ;)

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

(162) Во-во, я и говорю, череп треснет :))

Короче я понял, что примера мне не обломится, пошел я спать :o)

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

всем спасибо за интересное обсуждение, пожалуй и мне пора спать :)

Волшебник, а где обещанный вчера пример? :))

(167) Все-таки я надеюсь услышать его от тебя.

PR, я думаю, что в (25) ветке от v8: Вопрос по запросам; будет при соединении пустой запрос

(168) Я свое мяу в (93)+(94) сказал :))

(169) Не обязательно пустой, может быть и очень полным.

(169)Смотря какое соединение.

(169) А что, там было сказано, что соединение по этому полю, я вот считал, что соединение по ИСТИНА :))

(172) Так твой вариант будет? :))

Мдя...

Е мое, куча мегаспецов и НИКТО не может популярно по рабоче-крестьянски привести пример на две таблицы с двумя - тремя записями в каждой, когда соединение и объединение будудт давать разный результат :D

(176)Для того примера:

полное соединение
1    null
2    null
3    null
null 4
null 5
null 6

(176) Уважаемый, нам очень не хочется здесь 7-ую главу описания встроенного языка. Не могли бы Вы ее сами перечитать?

К (35) в другой ветке, ныне закрытой: результат имхо будет разным, если это два РАЗНЫХ поля!

(177) Это для полного соединения с условием. Без указания условия результат будет другим.

(177) Во-во, я и говорю :))
А разве это ДВА РАЗНЫХ поля? Я не зря просил уточнить это ;)

(179) Расскажите, пожалуйста, как при соединении две колонки поместить в одно поле?

Да е мое, приведите же пример наконец :o)
Тупой простой пример

(177) Если это одно поле, то результата при полном и внутреннем соединении будет NULL

(182) Очень просто, соединение делается ПО каким-то полям :))

(185) Не обязательно

(186) Но если это так, то два поля превращаются в одно, логично? :))

(187) Нет, не логично.

(188) Почему?

(188) Повторяю еще раз: внимательно прочитайте 7 главу из описания встроенного языка. Там черным по белому написано почему.

Блин, я в (16) и (19) привел два примера запросов, а в (90), (93) + (94) два примера на несколько записей, ОПРОВЕРГНИТЕ меня пожалуйста на похожем примере! :o)

(180)Согласен. В другом случае результат будет:

1 4
1 5
1 6
2 4
2 5
2 6
3 4
3 5
3 6

Елки-палки, может кто-нить (93)+(94) опровергнуть? Все сразу станет на свои места :))

(191) Примеры выбраны не показательными, это раз. Вы напрочь отказываетесь читать документацию, это два. И в третьих, что Вам мешает выполнить в консоли два простых запроса?:
Запрос1

Выбрать * из Таблица1
Объединить ВСЕ
Выбрать * из Таблица2

и Запрос2

Выбрать * из Таблица1 Соединение Таблица2


(193) А самое печальное, что во встроенной помощи 1С:Предприятия богатое количество примеров результатов соединений и объединений. Но нет, не хотят люди даже F1 нажать...

(194) Примеры предложил Стас ;) Согласен на другие реальные (а не 1, 2, 3...) примеры :))
Доку я читал и все это в общем случае понимаю, не могу придумать показательный пример, когда результат будет различным :o)
Два запроса мешает выполнить большое количество данных, среди которых может и не быть того, что нужно :o) Хочется пример на несколько записей

(196) Возьмите любой пример с количеством записей отличным от нуля и от двух.

(194) А если в первом запросе использовать не Объединить ВСЕ, а просто Объединить?
(195) Я читаю доку и побольше многих, даже написать сам попробовал :))
Просто сейчас хочется ПРОСТОЙ пример

(198) Штатной документации, на мой взгляд, очень наглядные и показательные примеры с объяснениями. Так же в документации достаточно четко прописана разница между "Объединить" и "Объединить ВСЕ".

(197) OK :))

Записи регистра Цены
1. Тапочки      ПродажнаяЦена    100
2. Вентилятор   ЗакупочнаяЦена   200
5. Светильник   ЗакупочнаяЦена   300

Записи регистра СкидкиПоНоменклатуре
1. Тапочки      РозничнаяСкидка  10%
2. Вентилятор   ОптоваяСкидка    20%
3. Подушка      ОптоваяСкидка    30%
4. Стол         РозничнаяСкидка  10%

Соединение по номенклатуре: 5 записей, верно?
Объединение без все: 5 записей, верно?

(199) Я (надеюсь) понимаю разницу между "Объединить" и "Объединить ВСЕ" :o)
Это когда две записи либо пытаются либо нет соединиться в одну, верно?

(200) ващет, при безусловном объединении (union) будет 9 записей..

(200) Да, нет.

(202) А я разве не написал, что объединение без ВСЕ? :))

(203) Почему нет, если соединение без ВСЕ?

По этому случаю прикупил книжецу далекую именно от 1С но близкую к T-SQL.Где для чайников разбираются подробно все типы соединений и объединений. Так доходчиво написано.На примерах. Часто ей пользуюсь.

(205) Глава 7, Описание встроенного языка.

Да . Если шо то PUBS рулит. Благо дело хоть пересчитать руками мона. Строк мало.Что помножилось , а что не успело или задвоилось

(207) Книги куда-то заиграл, есть только электронный вариант :o)
Глава 34? Подзаголовок какой?

+ (207) стр 1075

(+209) А, сорри, ты же написал, что 7 :o)
А я что-то про 7.7 подумал :o)
Сейчас посмотрю, по 8.0 книги е

(209) Справка - Поиск по справке - "Объединение запросов"

Млин, читаю:
"По умолчанию при объединении запросов полностью одинаковые строки в результате запроса, сформированные разными запросами, заменяются одной."
А разве NULL не складывается с любым другим значением?

(213) А при чем здесь NULL и сложение? И почему именно сложение, а не вычитание или умножение?

Итого в примере из (200) объединятся записи (1) и (1) в одну и записи (2) и (2) в одну, логично?

(214) Я имею в виду "сложение" записей в одну, то есть замену двух записей одной

(215) Нет, не логично. Еще раз перечитайте (213). Желательно громко, вслух, на распев.

(215) в 200 будет 9 записей.

(218) Это как так 9?

(218) Спасибо, мне уже доложили :)) (с)

(217) Где я не прав?

Первые записи регистров

Товар      ВидЦены          ВидСкидки          Цена    ПроцентСкидки

Тапочки    ПродажнаяЦена    NULL               100     NULL
Тапочки    NULL             РозничнаяСкидка    NULL    10%

Итого записи объединяются

"По умолчанию при объединении запросов польностью одинаковые строки в результате запроса, сформированные разными запросами, заменяются одной. Если тербуется, чтобы были оставлены разные строки, необходимо указать ключевое сллово ВСЕ." ЖКК, стр 1075

(221) Я это прочитал и уже давно сказал, что в моем случае ВСЕ НЕ используется :))

(220) что это?...

(222) а где у тебя в (200) полностью одинаковые записи?

(220) Никогда не думал, что придется в интернет конференции учить читать.
"По умолчанию при объединении запросов ПОЛНОСТЬЮ ОДИНАКОВЫЕ строки в результате запроса, сформированные разными запросами".
Покажите, пожалуйста, где в (220) ПОЛНОСТЬЮ ОДИНАКОВЫЕ строки?

Мда, я сам профессионал по зае****нию, но мне далеко до вас :D

(226) Научитесь читать, в жизни это умение очень помогает...

(224) Смотри 220, в чем первые записи различаются?

(226) ты не профессионал, ты любитель, потому как никому ничего не сумел заи...ть... разве что себе..

NULL и РозничнаяЦена одно и то же?...я в шоке (с)

(225) Так вот я же и спрашиваю, к примеру ПродажнаяЦена и NULL считаются различными значениями?

Товарищ налетел лбом на NULL... Для новичков простительно...

(231) Напишите запрос, который вернет результат операции сравнения этих двух значений.

null<>0

(232) Товарищ отказывается читать документацию - это никому не простительно.

(232) позвольте еще раз высказать Вам благодарность за неописуемо бесподобную фразу "я в шоке".

(229) :D
(232) Я в шоке, сечас меня в 1С:Ламеры запишут :D
(235) Я ПРОЧИТАЛ доку :o)
(234) А 100 = NULL?
(233) Сейчас сбацаю

думаю, надо записывать в SQL-ламеры))

(233)
Примерно так, только ВидСкидки заменил на ХарактеристикаНоменклатуры, нет поля ВидСкидки в типовой УТ :o)

ВЫБРАТЬ
   ЦеныНоменклатуры.Номенклатура,
   ЦеныНоменклатуры.ТипЦен,
   NULL КАК ХарактеристикаНоменклатуры,
   ЦеныНоменклатуры.Цена,
   NULL КАК ПроцентСкидкиНаценки
ИЗ
   РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры

ОБЪЕДИНИТЬ

ВЫБРАТЬ
   СкидкиНаценкиНоменклатуры.Номенклатура,
   NULL,
   СкидкиНаценкиНоменклатуры.ХарактеристикаНоменклатуры,
   NULL,
   СкидкиНаценкиНоменклатуры.ПроцентСкидкиНаценки
ИЗ
   РегистрСведений.СкидкиНаценкиНоменклатуры КАК СкидкиНаценкиНоменклатуры

(238) Записывайте, мне похрену, я в специалисты по сиквелу не записывался :))
Только свою точку зрения сначала докажите ;)

(239) И? :-)

(240) кстати, буду утверждать, что аббревиатуру SQL неправильно читаете...))

Уморили :o)
(242) Это не я придумал такое произношение :o)
(241) Сейчас проверить некогда уже, пора бежать, через энное время проверю, будет 5 записей, 9 или сколько еще :o)
Следующий вопрос, а если использовать СГРУППИРОВАТЬ или ИТОГИ, то есть не обращать внимание на детальные записи, результат будет разным или нет?

Все, побег по делам, до скорых встреч

(243) Кажется, что вопрос следует задать более развернуто, а то ничего не понятно.

(244) Имеется в виду, что если в запросе с ОБЪЕДИНИТЬ сгруппировать все с помощью СГРУППИРОВАТЬ, то есть избавиться от детальных записей или при выборке результат использовать группировки, описанные в ИТОГИ, то будет ли результат отличаться от варианта, когда исполльзуется СОЕДИНЕНИЕ с таким же группированием записей или использование итогов?

(243) слюши, дарагой, дафой учет мух и катлет вести раздельно да))) и сиквел не придумывали - так назывался язык?  предществующий SQL

(245) Результаты объединения и соединения в общем случае не совпадают. Сгруппировать тут никак не поможет. А итоги - это вообще операция с результатом запроса, которая выполняется на клиенте и фактически не относится к языку запросов.

(246) Дарагой, сиквел - это всего лишь транскрипция SQL, да!
Могу ошибаться, но где-то читал :o)
В общем я убег, приду, продолжим :o)

(248) ты не можеш ошибатся - ты ошибаешся относительно сиквел..

(247) когда могут совпадать результаты объединения и соединения?..

(250) При определенных структурах таблиц, при определенных данных в этих таблицах и при особых условиях соединения.

с точки зрения операций над множествами можеш описать разницу Join и Union?

(252) Это мне?

(253) ага.. для общего развития...

(248)История возникновения языка SQL восходит к 1970 году [8], когда
доктор Е.Ф. Кодд предложил реляционную модель в качестве новой
модели базы данных. Для доказательства жизнеспособности новой
модели данных внутри компании IBM был создан мощный исследова-
тельский проект, получивший название System/R. Проект включал
разработку собственно реляционной СУБД и специального языка за-
просов к базе данных. Так в начале 70-х годов появился первый иссле-
довательский прототип реляционной СУБД. Для этого прототипа раз-
рабатывались и опробовались разные языки запросов, один из которых
получил название SEQUEL (Structured English Query Language). С мо-
мента создания и до наших дней этот язык претерпел массу измене-
ний, но идеология и произношение названия остались неизменными
(аббревиатура SQL иногда читается «Эс-Кю-Эль», а иногда «Сиквел»)

(252) Union(A,B) = A U B
Join(A,B) = A x B

Ребятушки. А вы представьте когда не SQL сервер своей работой занимается, а на клиенте ,на таблицах значений реализованы по сути union и join. Путем многократных циклов и группировок . Сначала одну табличку набиваем потом другую. Открываем цикл .Перебираем и .т.д. Вот это пипец. Имеем 5 таблиц значений для получения одной итоговой. :) А кода то сколько , а кода :)

(257) Объем кода сильно зависит от того, какой алгоритм использовать :-)

Так всё-таки 9 записей будет? Полное Соединение сваяет все возможные комбинации?

(259) Если речь идет о полном соединении без условий, то записей будет 19...

Почти два часа меня не было, а по делу ничего.
Ладно, буду сам копать, раз Волшебник гордо молчит, а остальные не могут/не хотят объяснить по рабоче-крестьянски :o)

(261) а что тебе еще по делу?.

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

дополнение столбцов - ключевое отличие соединения от объединения.

В общем-то опытно-экспериментальным путем я все выяснил, что хотел :o)
Остался только один вопрос, но с этим я как-нить разберусь, что такое NULL и зачем он нужен, раз ни с чем ни складывается?

Всем спасибо, все свободны :))

(263) Я ниче не понял из того, что ты сказал :o)

(264) ты потрудись, и обязательно дойдеш до понимания.
Кстати, для этого предлагаю поизучать объединения и соединения используя, допустим, тот же самый MS SQL

(265) Как-нить в другой раз, не до этого :o)

и еще, попробуй объединить два запроса с разным количество полей в предложении ВЫБРАТЬ))..
тоже самое с СОЕДИНЕНИЕ взлетит на ура))

(267) Ну конечно, а как быть в случае, если какое-то поле должно браться из обоих запросов и по нему соединение?
Возьмешь из одного, в записях из другого будет NULL и наоборот.
Соединение рулит? ;)

(+268) Я, впрочем, знаю, как это обойти, но решение мне не больно нравится :o)

ничо в 268 не понял..

(270) Читай (265) :))

(271) у меня вопроса как (0) не возникало, так сслыка на 265 абсолютна некорректа и с твое стороны выглядить как мелкая месть..

Я в (263) тоже не понял, почему это в одном случае добавляются строки, а в другом столбцы :o)
Прямо что-то типа "Летят по небу два крокодила, один красный, а другой низко. Сколько мне лет?" :o)
На свой вопрос я уже нашел ответ, ибо (261) :o)
По поводу мести ты не прав, мне просто лень объяснять :))

Hominis est errare, insipientis perseverare...

(274) Помедленнее, я записываю :))