Столкнулся сегодня вот с такой конструкцией:


SELECT .........
FROM table1, table2
WHERE table1.field *= table2.field


Вот что такое это "*="? Я, конечно, смутно догадываюсь, что так левое соединение записали, но в документации ни разу такого не встречал.

это устаревшее и депрекейтед left outer join

+(1) Да и вот таким:
table1, table2
тоже пользоваться не стоит...

(2) это древнеэскуэльский синтаксис, которыым пользовались еще до того, как Кирилл с Мифодием соединения придумали

я вот предлагаю инновацию:
a~b <=> a=b or (a is null and b is null)
a~=b <=> a=b or a is null
a=~b <=> a=b or b is null
a~=~b <=> a=b or a is null or b is null

+(4) ничего нового, просто синтаксический сахар

(3) Кто бы спорил :)
Но согласись, что это не значит, что такми синтаксисом стоит пользоваться, когда космические корабли бороздят...

От жеж блин, как я ишшо молод то ...

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

(6) ну, ado же вроде сказал, что он чье-то мумиё разгребает, видимо очень окаменелое попалось

(4) думаешь, скулю реально нужны эльфийские руны?

(8) Да вроде не такой уж и древний код был ...

(7) Молодца! :)
(8) Либо, пейсатель не совсем вменяемый был... Глянь, например, перлы от1С, которые во встроенной справке по язуку запросов живут. Они там на полном серьезе именно такому связыванию учат...

(10) значит пейсатель мануал по SQL читал еще с папируса

(9) поверь паскалисты совершенно не плачут
когда пишут a=a+b вместо a+=b
этож на любителя

(11) Думаю, в 1С динозавров от IT хватает ;-)

(13) Паскалисты пишут a:=a+b !

+(15) Ибо нефиг одним знаком две разные сущности обозначать ;-)

(2) С чего бы? простое произведен е таблиц. Зачастую полезно.
Например в 1С: Все склады+ все товары.

(17) ... равно недостаточно памяти для завершения операции :)

(17) Сунешься потом в такой код и потопаешь за водкой, мылом и веревкой. И приэтом будешь бурчать что-то типа "Машу вать!!!"...
Код абсолютно нечитабльным получается.

(15) точно! у тех правда тоже 2 сущности, но несколько по другому природа

(17) я не понял что ты написал, честно

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

(22) Паскалисты бьют сишников? :)

(22) ты знаешь в других суть 2 разных это = и ==

(24) Но есть расово неверные языки, где = и = записываются одинаково. Один из них мы все знаем ;-)

(17) Если честно, не представляю, где на практике нужно полное декартово произведение таблиц.

(25) найти все заказ и реализации по ним, сопоставить их, при этом вывести также и те и другие, которым нет сопостовления, как то так

(24) я ни где не сказал, что паскаль - единственно верный язык

(27З) меня синтаксис смутил

+(27) более того, я его люто недолюбливаю
ЗЫ На религиозной почве без особенных причин

(26) Полное внешнее соединение. Это немножко другое.

(21) А что непонятного?
(25) Мне нужно. Например есть товар, который должен быть на каждом складе.
Условие для товра известно. Как получить таблицу товар-склад?
Она же будет фильтром для всего остального.

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

+(32) блин, это внутреннее, а не декартово

Чего спорите? Вначале речь ршла всего-навсего о представлении кода и удобстве последующего его чтения...

(34) истину рожают...

(35) А... Тады не мешаю...

+(33) любое соединение с таблицей констант

(33)(34)(35) Конструкцию из Oracle первых трех записей в студию.....

(38) ты как на Лубянке, что такого я сказал в (33)?

Сегодня возник спор - как избежать грязного чтения в SQL 2008 БД 1с77?
Какой хинт использовать и режим сеанса.

(40) Зачем ты собрался избегать грязногочтения в семерке?

Например, _1SJOURN сдуру повешен триггер на INSERT/UPDATE/DELETE

(41) Для импорта документов

(42) И почему это сдуру? У нас, например, висят эти триггера. И как это связано с (40)?

(44) А если транзакция оптимистическая?

(43) Что-то тебя кидает из строну в сторону... То связывание, то Оракл, то грязное чтение...

(45) И что?

(46) У Oracle совершенно иная конструкция и концепция получения первых записей.
Можешь возразить? Нет в Pl/SQL предиката TOP.

(47) Ну а если потом пойдет откат транзакции?

(48) Вот про Оракл я вообще ничего не могу возразить - не знаю я его абсолютно. Можешь грузить меня чем хочешь - поверю :)

(49) Давай ты как-то поподробнее проблему опишешь? А то у меня такое чуство, что обсуждаем сферического коня...

(38) Select * from table where rownum <= 3;

(50) Да нет, грузить я тебя вовсе не собираюсь.
Просто по subj, ведь полно сиквельных диалектов....

(52) Молодец

(53) Понял :) Еще один буквоед. Прямо как я :)

(51) В двух словах - всё банально - дабы не поднимать _1SUPDTS решили создать свою таблицу и писать в неё изменения, тогда, пока триггер отрабатывает запись с IDDOC существует, другая БД в этот момент читает _1SJOURN и видит грязные данные, тянет их к себе. В базе-источники потом идет откат  транзакции, и IDDOC освобождется, что приводит к искажению инфы. Да, криво. Да, решаемо и решено.

(55) Просто многие привыкли, что хинтом (NOLOCK) можно ограничить себя, егда далеко не всегда.

(56) Дык не проблема же? Блокировка на строку на момент считывания данных. И всё. А, не всё. Еще повторная поставка в обмен для очситки базы-приемника.

(58) А ты проверь.

(58) Да проблем нет. Всё решаемо. Вопрос как?
Тут же всего человек 20 скуль знают. Остальные - статисты.

Допусти, ну напишем статю как этого избежать. Ребят, и вправду, много писали из рассчета, что это кто-то оценит. Оценили? Нет. Думаешь у Сережи Осипова не было хороших идей? Были. Во что превратилось всё?

(59) Чего именно проверить? Несколько лет работает.
(61) Вот не надо про этого...

истина имеет сучковатую природу - туго идет...

(62) Умный -  поймет, дурак - не оценит.
"Работает - и не трогай" (с)

(63) Но резво входит

(25) "Если честно, не представляю, где на практике нужно полное декартово произведение таблиц."

для хитровы***анных расчетов интервалов например.