powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему ораклисты так не любят MS SQL?
25 сообщений из 457, страница 16 из 19
Почему ораклисты так не любят MS SQL?
    #33392361
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Честно говоря, не думал, что это вы серьезно спрашивали.
Хм. Удобный подход.

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

вот еще три
/topic/226311&hl=oracle+%ee%f0%e0%ea%eb
Тема в форуме MS SQL создана человеком, который писал только в MS SQL. Да, это безусловно ораклист, который не любит MS SQL.

И, кстати, судя по всему, тем в "Сравнении СУБД" Вам уже не хватило. Вы не пробовали поискать по форуму оракла, сколько там аналогичных тем от мигрантов?

/topic/190896&hl=oracle+%ee%f0%e0%ea%eb+sql
Изрядно притянуто за уши. Тема "Объективно существующее нарушение стандарта ANSI SQL в MS SQL SERVER" если и тянет на флейм, то только в глазах очень пристрастных фанатов.

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

/topic/202804&hl=oracle+%ee%f0%e0%ea%eb+sql
Согласен, зачтено. Собственно из всех пяти теперь тем - единственный четкий пример.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392382
Склероз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUSТо есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц и таким образом избавиться от неоднозначности и дать возможность оптимизатору построить наиболее эффективный план запроса. Думаю не стоит напоминать, что чем более явно описаны соединения, тем легче оптимизатору правильно решить, что будет наиболее выгодным при выполнении запроса.
Это в сайбез так? Бред какой то :)
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392387
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerКстати, подскажите - можно ли отформатировать from с использованием join-ов так, чтобы
Спасибо за ответы. Названные способы однотипны, но пока к сожалению становятся неудобными, как только появляются неравномерные длины названий таблиц и дополнительные слова в join-ах, то есть начинается что-то типа

Код: plaintext
1.
2.
3.
4.
5.
from
            DocumentProperties p 
join        Documents d             on d.doc_id = p.doc_id
left join   Subscribers s           on d.subscriber_id = s.subsriber_id
...

это, конечно, решает поставленную задачу, но имхо само по себе довольно малочитабельно.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392407
Сергей84
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а если так
автор
from
DocumentProperties p
join Documents d on d.doc_id = p.doc_id
left join Subscribers s on d.subscriber_id = s.subsriber_id
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392412
Сергей84
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ой ошибся, сори
Код: plaintext
1.
2.
3.
from
            DocumentProperties    p 
join        Documents             d             on d.doc_id = p.doc_id
left join   Subscribers           s             on d.subscriber_id = s.subsriber_id
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392468
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чем лично мне нравиться писать через join (я кстати тоже долго не мог привыкнуть)

допустим есть запрос
Код: plaintext
1.
2.
3.
select *
from a
join b on c=d
join e on f=g
и нам надо одну таблицу исключить (для отладки) - тогда коментим одну строчку и все
Код: plaintext
1.
2.
3.
select *
from a
--join b on c=d
join e on f=g
если бы условия были во where надо было бы в двух местах исправлять

кагда таблиц с десяток, то выбрать таблицу и условия, по которым она связана уже становится тяжело
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392576
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSХочется посмотреть на пример. Причем такой, по которому оптимизатор однозначно бы соединял между собой b и c внутренним соединением и приводил результат соединения, как внешнее соединение к таблице a.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> with
   2     d as (select /*+ NO_MERGE */ b.* from a, b where a.a_id = b.a_id)
   3   select
   4     *
   5   from
   6     d, c
   7   where
   8     d.c_id = c.c_id (+) ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 7  Card= 1  Bytes= 39 )
    1      0    HASH JOIN (OUTER) (Cost= 7  Card= 1  Bytes= 39 )
    2      1      VIEW (Cost= 5  Card= 1  Bytes= 26 )
    3      2        HASH JOIN (Cost= 5  Card= 1  Bytes= 39 )
    4      3          TABLE ACCESS (FULL) OF 'A' (TABLE) (Cost= 2  Card= 1  Bytes= 13 )
    5      3          TABLE ACCESS (FULL) OF 'B' (TABLE) (Cost= 2  Card= 1  Bytes= 26 )
    6      1      TABLE ACCESS (FULL) OF 'C' (TABLE) (Cost= 2  Card= 1  Bytes= 13 )

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

ASCRUSТо есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц и таким образом избавиться от неоднозначности и дать возможность оптимизатору построить наиболее эффективный план запроса.
Менее эффективный план. Поскольку сужает пространство вариантов, и наиболее эффективный план запросто окажется отсеянным.

ASCRUSДумаю не стоит напоминать, что чем более явно описаны соединения, тем легче оптимизатору правильно решить, что будет наиболее выгодным при выполнении запроса.
"Наиболее выгодным из чертовски ограниченного пространства вариантов".

Правда, Oracle здесь выглядит молодцом, поскольку все-таки умеет начхать на прописанный порядок join-ов и выбрать эффективный вариант.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392612
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей84
Имхо - ужасно, по крайней мере если работать с этим в обычном текстовом редакторе. Хотя безусловно, вопрос вкусов.

SergSuperи нам надо одну таблицу исключить (для отладки) - тогда коментим одну строчку и все

Код: plaintext
1.
2.
3.
select *
from a
--join b on c=d
join e on f=g


Хм. А поля из b не входят в select? Или Вы всегда пишите *? А join e не отваливается с ошибкой "field [f] does not exist"? А в where на поля из b не наложено никаких дополнительных условий?
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392651
Сергей84
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну как говорится на вкус и цвет
во всяком случае для меня в QA - так удобнее, после чего я делаю обчно Ctrl+C и в 1С Ctrl+V добавляю ковычки что типа это текстовая переменная и все, если же что-то где-то неконтачит, открываю Profiler вылавливаю , вставляю в QA и опять получаю хорошо отформатированный и наглядный текст запроса
на счет 2-го вопроса, хотя он был задан и не мне, я предпоситаю переменные одной таблици и условия описывать одной строкой, типа:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select
       a.a1, a.a2
      ,b.b1, b.b2
from
      a 
          inner join b on a.a1 = b.b1
where
      a.a2 =  1 
      and b.b2 in ( 1 , 2 , 3 )
благодаря этому легко исключается таблица из обработки
сложнее когда поле является вычисляемым, например a.a1+b.b1 и т.п.
P.S. все изложенное ИМХО, и настаивать на изменении своих взглядов на ворматирование запросов не буду как кто хочет - пусть так и делает
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392693
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinПредлагаю сойтись на том, что это "дело привычки".
Дело привычки - безусловно. Но раз уж поднялось, хочется понять какие-то объективные различия того и другого подхода - пусть и не сходясь в оценке этих различий.

softwarerИз-за этого достаточно часто начинают пихать в join дополнительные условия, которым вообще-то место именно в where или в подзапросе

pkarklinРассмотрим такой запрос:
.....
Т.е. вывести все записи из T2 по определенному SomeID плюс NULL. Таки надо пихать именно в JOIN.
Отнюдь. Если я правильно понял, что Вы хотите получить...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
SQL> create table t1 as
   2   select  1  id, 'a' id_name from dual union all
   3   select  2 , 'b' from dual ;

Table created

SQL> create table t2 as
   2   select  1  id_fk_id,  1  some_id, 'aa' some_value from dual union all
   3   select  1 ,  2 , 'bb' from dual union all
   4   select  2 ,  2 , 'cc' from dual ;

Table created

SQL> select *
   2   from t1, t2
   3   where t1.id = t2.id_fk_id (+) and  1  = t2.some_id (+) ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------
          1  a                 1            1  aa
          2  b                

pkarklinНасчет " join с inline view" надо конкретный запрос увидеть, чтоб понять, что Вы имеете ввиду.
Да собственно говоря, Ваш же пример. Если взять суть того, что хочется получить, то для наглядности требуемого его стоит записать примерно так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SQL> select *
   2   from
   3     t1 left outer join (select * from t2 where some_id =  1 ) t2 on t1.id = t2.id_fk_id ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------
          1  a                 1            1  aa
          2  b                             

Не знаю, насколько это универсальный термин, но для Oracle такой подзапрос принято называть inline view.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392717
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей84благодаря этому легко исключается таблица из обработки
Я как раз и имею в виду, что в Вашем примере, чтобы исключить таблицу b из обработки, нужно закомментировать три строки. Если переписать его в том же стиле без join, как

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select
       a.a1, a.a2
      ,b.b1, b.b2
from
      a
      ,b 
where
      a.a2 =  1 
      and a.a_id = b.b_id and b.b2 in ( 1 , 2 , 3 )

для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392740
Чубурашка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select
       a.a1, a.a2
      ,b.b1, b.b2
from
      a
      ,b 
where
      a.a2 =  1 
      and a.a_id = b.b_id and b.b2 in ( 1 , 2 , 3 )

для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента.
К тому же, это выглядит читабельней.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392910
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerДело привычки - безусловно. Но раз уж поднялось, хочется понять какие-то объективные различия того и другого подхода - пусть и не сходясь в оценке этих различий.

Ок. Попробуем. Для сиквел сервера в смысле плана выполнения следующие запросв эквивалентны:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SELECT
  *
FROM
  @T1 T1
  LEFT OUTER JOIN @T2 T2 ON
  T1.id = T2.ID_FK_ID AND
  SomeID =  1 

SELECT
  *
FROM
  @T1 T1
  LEFT OUTER JOIN (select * from @t2 where someid =  1 ) t2 on t1.id = t2.id_fk_id

Так что тут действительно дело вкуса. А вот такой уже не пройдет на сиквел сервере:

Код: plaintext
1.
2.
select *
from @t1 t1 , @t2 t2
where t1.id *= t2.id_fk_id  and  1  *= t2.some_id

потребовав ссылок на колонки в объединении.

НА счет объективного различия. Сравним результаты, казалось бы одного и того же запроса:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
SELECT
  *
FROM
  @T1 T1
  LEFT OUTER JOIN @T2 T2 ON
  T1.id = T2.ID_FK_ID
WHERE
  T2.SomeID IS NULL

SELECT
  *
FROM
  @T1 T1, @T2 T2
WHERE
  T1.id *= T2.ID_FK_ID AND
  T2.SomeID IS NULL

id          id_name    id_FK_ID    SomeID      someval    
----------- ---------- ----------- ----------- ---------- 

( 0  row(s) affected)

id          id_name    id_FK_ID    SomeID      someval    
----------- ---------- ----------- ----------- ---------- 
 1            a          NULL        NULL        NULL
 2            b          NULL        NULL        NULL

( 2  row(s) affected)
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392957
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще, я не представляю, как, например, следующий запрос можно переписать с объединением в WHERE:

Код: plaintext
1.
2.
3.
4.
5.
SELECT 
  *
FROM
  Table1 
  LEFT OUTER JOIN Table2 ON 
  Table1.col1 BETWEEN Table2.col2 AND Table2.col3
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392972
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer Сергей84благодаря этому легко исключается таблица из обработки
Я как раз и имею в виду, что в Вашем примере, чтобы исключить таблицу b из обработки, нужно закомментировать три строки. Если переписать его в том же стиле без join, как

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select
       a.a1, a.a2
      ,b.b1, b.b2
from
      a
      ,b 
where
      a.a2 =  1 
      and a.a_id = b.b_id and b.b2 in ( 1 , 2 , 3 )

для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента.
В таком случае действительно всё равно. Но в 80% случаев удаётся и в одной строке. Например в данном случае если мы добавляем таблицу b то логичней все её условия написать в условиях связи( on a.a_id = b.b_id and b.b2 in (1,2,3) ).Таблицу "а" мы так легко не выкинем, но чаще имеет смысл выкидывать сразу "а" и "b" - "b" вторичная по отношению к "а"
ЧубурашкаК тому же, это выглядит читабельней.
Ce,]Очень субъективно. Мне это представляется как свалка таблиц и огород условий.
А так добавили таблицу - и тут же её условия.

А вообще пару лет назад я тоже как вы думал. У вас еще всё впереди :)

Топик плавно перерос в тему "А чего это любители WHERE не любят JOIN?"
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33392991
Чубурашка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuperУ вас еще всё впереди
Видать у softwarer`а тоже
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393025
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper
В таком случае действительно всё равно. Но в 80% случаев удаётся и в одной строке. Например в данном случае если мы добавляем таблицу b то логичней все её условия написать в условиях связи( on a.a_id = b.b_id and b.b2 in (1,2,3)
О! Позволю себе отметить этот момент, почему: потому что он в точности иллюстрирует мой тезис насчет соблазна начать тащить во from то, чему полагается быть в where или в inline view.

Обратите внимание: практически Вы решаете таким образом то, что я назвал недостатком join; Вы снова группируете в одном месте все, что относится к одной таблице. Разница только в том, что Вы предпочитаете собирать все во from и работать без where, я - наоборот.

Не готов сходу сказать, заменяемы ли эти подходы, то есть можно ли написать в join нечто, чего нельзя написать в where. Но если подходить сугубо логически - таким образом Вам приходится тащить во from то, что не имеет никакого отношения к "соединению". where в этом плане более универсален; собственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where.

SergSuperОчень субъективно. Мне это представляется как свалка таблиц и огород условий.
Угу. Мне - как книга с оглавлением и текстом. Видно, что связывается, если есть вопросы, можно посмотреть, как связывается.

Собственно, если бы я нашел устраивающее меня решение двух задач: во-первых, именно "четко видеть таблицы, участвующие в запросе", и во-вторых "разумным образом писать условия, не ложащиеся в концепцию связи таблиц", например, условия на несколько таблиц - думаю, согласился бы с Вами.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393093
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerсобственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where.

Дежавю. ;) Т.е. представить совсем наоборот, как происходит на самом деле!
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393108
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinА вот такой уже не пройдет на сиквел сервере:
Хм. А что-нибудь типа

Код: plaintext
where (t1.id,  1 ) *= (t2.id_fk_id, t2.some_id)

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

pkarklinНА счет объективного различия. Сравним результаты, казалось бы одного и того же запроса:
Ну, написать "казалось бы одинаковые" запросы можно всегда и любым инструментом. А можно писать так, как нужно:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SQL> select *
   2   from t1, t2
   3   where t1.id = t2.id_fk_id (+) and t2.some_id is null ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------

SQL> select *
   2   from t1, t2
   3   where t1.id = t2.id_fk_id (+) and t2.some_id (+) is null ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------
          1  a                             
          2  b                             

pkarklin
И еще, я не представляю, как, например, следующий запрос можно переписать с объединением в WHERE:
Хм. Не вижу проблемы.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL> select *
   2   from t1, t2
   3   where t1.id between t2.id_fk_id (+) and t2.some_id (+) ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------
          1  a                 1            1  aa
          1  a                 1            2  bb
          2  b                 1            2  bb
          2  b                 2            2  cc

SQL> select *
   2   from t1, t2
   3   where t1.id between t2.id_fk_id (+) and t2.some_id (+) -  1  ;

        ID ID_NAME   ID_FK_ID    SOME_ID SOME_VALUE
---------- ------- ---------- ---------- ----------
          1  a                 1            2  bb
          2  b                             

Хм. Пока что у меня сложилось впечатление, что в MS SQL в силу каких-то странных соображений конструкция outer join via * весьма и весьма ограничена в возможностях - и все.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393117
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinДежавю. ;) Т.е. представить совсем наоборот, как происходит на самом деле!
Если помните, SQL - декларативный язык, призванный максимально разделить "что делать" и "как это делается". Безусловно, постепенно нужно закапываться в реализацию, но вываливать ее на новичка оправданно только если нужно убедить этого новичка бежать подальше от этого SQL.

Этой фразы (с расшифровкой понятия картезиана) хватает, чтобы человек, никогда не имевший дело с БД, понял происходящее и правильно пользовался - проверено, лично мной. На столь же понятное объяснение join-ов - я бы с удовольствием посмотрел.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393130
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerО! Позволю себе отметить этот момент, почему: потому что он в точности иллюстрирует мой тезис насчет соблазна начать тащить во from то, чему полагается быть в where или в inline view.
Не сомневался что вы зацепитесь за это :)
А я просто предложил писать как можно логичней. Если это еще одна основная таблица, то тогда конечно надо условия писать во where, но тогда и выкидывать её из запроса смысла нет. А если это, допустим некие аттрибуты, то очень даже логично держать условия вместе с таблицей.

softwarer собственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where.
А меня в школе учили писать перьевой ручкой, хотя вовсю уже были шариковые.
Я тоже себе так представлял - но это потому что по другому через where не написать.
(Хотя на самом деле насчет новичков - это согласен, им полезно)

softwarer
...если бы я нашел устраивающее меня решение двух задач: во-первых, именно "четко видеть таблицы, участвующие в запросе"...
осталость только научиться четко видеть :))
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393163
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andy stмне, к примеру он уже не светит ввиду свежеобнаруженных баговВот это на самом деле важно.

Какие баги вы уже обнаружили в MSSQL2005?

Вопрос не праздный.
Т.к. мы только что приступаем к тестированию MSSQL2005.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393186
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperНе сомневался что вы зацепитесь за это :)
Не столько ради Вас, сколько ради pkarklin-а :)

SergSuperА я просто предложил писать как можно логичней. Если это еще одна основная таблица, то тогда конечно надо условия писать во where, но тогда и выкидывать её из запроса смысла нет. А если это, допустим некие аттрибуты, то очень даже логично держать условия вместе с таблицей.
А если в запросе три основных таблицы? При этом в рамках отладки одну из них желательно выкинуть?

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

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

SergSuperЯ тоже себе так представлял - но это потому что по другому через where не написать.
Дык в этом-то и идея SQL-я как языка. Согласитесь, довольно трудно и несколько странно объяснять непонимающему человеку, почему я вроде бы пишу операцию join, типа

Код: plaintext
1.
from
  a join b on (a.v1 = b.v1) join c on (b.v2 = c.v2)

а если посмотреть в план - там будет merge join cartesian, и это будет наиболее эффективным планом для этого запроса. С другой стороны, с декларативным подходом никаких непониманий не возникает; написали фильтр, сервер выбрал наиболее эффективный способ его реализации, все замечательно.

SergSuper
осталость только научиться четко видеть :))
Дык уже. Наиболее удобный способ четко видеть я и использую
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393227
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerХм. А что-нибудь типа ...

Такой запрос для MS SQL синтаксически не верен.

softwarerВпрочем, в любом случае это во-первых означает таки желательность использования inline view, во-вторых, смело можно назвать недостатком реализации (по крайней мере логики в таком ограничении я не вижу).

Эээ... Не вижу недостатка ни в использовании inline view (хоть такого термина и не существует для MS SQL), и уж тем более в реализации. Вряд ли можно отнести к недостатку реализации "запрет" на написание всего и вся в предложении WHERE. IMHO.

softwarerНу, написать "казалось бы одинаковые" запросы можно всегда и любым инструментом. А можно писать так, как нужно:

Я ничуть не сомневался, что вы напишите "правильный" запрос. Хотя ввод ANSI стандартом объединение во FROM как раз и был призван устранить неодназначность, которую я описал!

softwarerПока что у меня сложилось впечатление, что в MS SQL в силу каких-то странных соображений конструкция outer join via * весьма и весьма ограничена в возможностях - и все.

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

Хотя вот эта фраза, которую Вы непервый раз произносите:

softwarerсобственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where.

Полностью объясняет Вашу "любовь" к WHERE.

softwarerЭтой фразы (с расшифровкой понятия картезиана) хватает, чтобы человек, никогда не имевший дело с БД, понял происходящее и правильно пользовался - проверено, лично мной. На столь же понятное объяснение join-ов - я бы с удовольствием посмотрел.

Я не представляю уровень новичка, которому нужно было бы объяснять про прямое, левое и правое объединение более, чем их определение!!! Или этому новичку надо чем-нибудь другим заниматься. А вот "объяснение" с искажением сути происходящего, то есть с искажением того, что он увидит в плане выполнения запроса считаю в корне не правильным.
...
Рейтинг: 0 / 0
Почему ораклисты так не любят MS SQL?
    #33393248
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то с полгода назад в Инете читал статейку, где JOIN & WHERE проходили под таким соусом (м.б. совру - тогда киньте в меня продуктом переработки пищи, т.е. стулом, но желательно не жидким):
- В случае объединения с JOIN данные из связанных таблиц сначала фильтруются по условиям указанным в нем - потом объединяются. Затем из результирующего набора "вычеркиваются" записи не соответствующие WHERE
- В случае объединения только с WHERE создается результирующая как декартово произведение всех таблиц, затем не соответствующие WHERE записи "вычеркиваются".

Пару раз пытался уловить разницу по скорости/эффективности (правда не особо старался) - не получилось. Так что на практике использую и то и другое. Что в данный момент удобнее.
...
Рейтинг: 0 / 0
25 сообщений из 457, страница 16 из 19
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему ораклисты так не любят MS SQL?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]