Локшин Марк softwarerЧему равен результат операции 5/0?
Согласно математическому определению данной операции результат будет равен бесконечности.
А нельзя ли уж процитировать само определение и сказать, откуда Вы его взяли?
Кстати, правильно ли я понял, что Вы утверждаете, что 0 * oo = 5?
Локшин МаркКстати, подумайте, что результаом применения операции может быть "неопределено".
И зачем думать об этом, если это то, о чем я говорю?
Локшин МаркВ отличае от *=, если такие аналогии проводить, то будет равно то-ли 5 то-ли 2, в зависимости от того как звезды на небе расположены.
Аналогия неверна и отличия нет. В обоих случаях - попытаетесь ли Вы выполнить на сервере "неопределенное" деление либо "неопределенную" связку - сервер выдаст сообщение об ошибке, суть которого именно в неопределенном результате операции. Если бы он этого не сделал, это была бы ошибка реализации сервера.
Тем не менее, стоит так же отметить, что "то ли два, то ли пять" - это и есть неопределенность. В школьной математике Вы должны были проходить примерно следующее обоснование деления на ноль: чтобы вычислить результат деления на ноль, составим уравнение C/0 = x, где C - константа. Оно равносильно C = 0 * x, и по определению нуля оно выполняется для любого x (в старших классах, может быть, добавят "меньше бесконечности). И дальше объясняют, что раз любой x является решением исходного уравнения - и два, и пять, и минус пи - то результат неопределен, его нельзя однозначно вычислить.
Локшин МаркИ как Вы себе это представляете?
Так себе и представляю. Есть определенные правила расстановки приоритетов в join-ах. Применить те же правила для связок, написанных в where в том порядке, в котором они там написаны, ругаясь на непредставимые в терминах join-а комбинации.
Локшин Марк softwarerно править запрос, не понимая логики соединения таблиц, я бы не рискнул.
Т.е. чтобы прицепить к конкретному справочнику по left join, допустим подчиненную таблицу при типе связи "один к одному" Вы досканально изучаете весь запрос на 5 экранах вглядываясь во все условия фильтрации?
Обратите внимания, как грубо Вы передернули от моего "логика соединения таблиц" к "все условия фильтрации".
Простите, но по этой причине мне не хочется отвечать на этот вопрос.
Локшин МаркА с какой стороны (+) написать ему уже думать будет не нужно?
Теоретически, наверное, нужно. Практически - никогда не встречал человека, который бы провозгласил что-то типа "блин! опять не с той стороны написал".
Локшин Марк softwarerИ вроде как выдвинули именно этот аргумент в пользу их использования, то есть в обоснование их появления.
Нет. Я говорил только про неоднозначность синтаксиса с *=.
OK. Давайте окончательно поставим точку в этом вопросе. Выберите, пожалуйста, один из следующих вариантов:
1) "Неоднозначность синтаксиса с *=" является существенным аргументом в пользу ansi join-ов, достаточным, чтобы не приводить других аргументов.
2) "Неоднозначность синтаксиса с *=" является существенным аргументом в пользу ansi join-ов; другие аргументы есть (где?) и в сумме их достаточно.
3) "Неоднозначность синтаксиса с *=" упомянута для полноты коллекции и не является существенным аргументом (а где существенные и о чем идет спор - непонятно).
Локшин МаркА тогда вопрос напрашивается сам собой - а какого черта нужно было так в схеме называть отношения, чтобы потом их все время сокращать.
Я, кажется, предлагал вынести это в отдельный топик.
Для ответа удобно воспользоваться понятием namespace. Проектируя схему, необходимо управлять пространством в несколько тысяч имен, которые нужно достаточно четко разделять - поэтому появляются сущности, например, ITEM$GROUPS, ORG$GROUPS и так далее. Пространство имен в запросе куда уже - порядка десятков, поэтому детализированное разделение как правило необязательно и только замусоривает код.
Второй момент, который также влияет на этот процесс - роль таблицы в запросе. Допустим, если мне нужны контрагенты, я предпочту оперировать именно этим алиасом, даже если таблица называется, допустим, Организации. В этом же запросе та же таблица может всплыть под алиасом "банки" - а может и не всплыть, смотря по логике запроса.
Наконец, существует момент с подзапросами. Довольно часто с точки зрения восприятия запроса уместно выделение подзапроса (с его фильтрующими условиями) с подстановкой его на то место, где раньше была таблица. То есть
1.
2.
3.
4.
select
....
from
organizations org
...
заменить на
1.
2.
3.
4.
select
....
from
( select * from organizations where is_alive = 1 ) org
....
При использовании алиасов это довольно естественно; если же везде применять имена таблиц и обозвать подзапрос именем таблицы, это здорово дезориентирует; конечно, можно привыкнуть, но не думаю, что это хорошая практика.
Локшин МаркПричем сокращать ВЕЗДЕ ОДИНАКОВО, иначе у Вас это извините не технология, а форменный бардак будет?
Думаю, у нас разное понимание ВЕЗДЕ ОДИНАКОВО. Для меня это - используя одинаковую и достаточно прозрачную логику. Для Вас, подозреваю - нечто другое.
Локшин МаркНепонятно, зачем вводить еще одну систему - сокращений с полной ее реалищацией исключительно силами программиста. От чего здесь стиль будет более единый? У Вас также появятся аналоги суффиксов.
Хм. Вы пытаетесь посмотреть сквозь шоры своей системы. В ней, безусловно, придется делать именно суффиксы. Лично я запрос
1.
2.
3.
from
com$organizations client,
com$persons head,
com$persons manager
полагаю более "единостильным", нежели
1.
2.
3.
4.
from
....
com$organizations,
com$persons_head,
com$persons_manager
и суффиксы вижу только во втором варианте.
