ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Вопрос по оператору JOIN
25 сообщений из 29, страница 1 из 2
  1  все
Вопрос по оператору JOIN
    #38264652
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
Уже много лет работаю с SQL Server, но недавно столкнулся с синтаксисом, который до этого не встречал - в банальном JOIN.
Код: sql
1.
2.
3.
    JOIN ...
        JOIN ... ON ...
    ON ...


Пример:
Код: sql
1.
2.
3.
4.
5.
6.
select t1.Caption as Name,
    t2.Number + t3.Number as Number
from dbo.Table1 t1
    left join dbo.Table2 t2
        join dbo.Table3 t3 on t2.ID = t3.Table2_ID
    on t2.Table1_ID = t1.ID



Вопрос: какие плюсы (или минусы) такого синтаксиса, когда был введен и вообще откуда это???
Есть-ли какая нибудь информация или название этой конструкции? Также буду рад ссылкам.
Поиск ничего не дает, т.к. этот оператор очень распространен.
...
Рейтинг: 0 / 0
20.05.2013, 15:18
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264667
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
BOL
<joined_table> ::=
{
<table_source> <join_type> <table_source> ON <search_condition>
| <table_source> CROSS JOIN <table_source>
| left_table_source { CROSS | OUTER } APPLY right_table_source
| [ ( ] <joined_table> [ ) ]

Т.е. приведенный вами пример есть всего лишь дополненный сервером документированный синтаксис
такой синтакис существует в документаиции как минимум с версии sql2000
...
Рейтинг: 0 / 0
20.05.2013, 15:28
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264676
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
Да, но по какой-то причине его никто не использует
Это можно увидеть даже на страницах нашего форума.
Просто я пытаюсь решить для себя, стоит-ли применять такую конструкцию
...
Рейтинг: 0 / 0
20.05.2013, 15:33
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264679
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
VRafaelДа, но по какой-то причине его никто не использует
Вы провели исследования ?

VRafaelЭто можно увидеть даже на страницах нашего форума.
Что "это" ? Мировую статистику использования той или иной возможности синтаксиса ?

VRafaelПросто я пытаюсь решить для себя, стоит-ли применять такую конструкцию
Это обыкновенный join.
...
Рейтинг: 0 / 0
20.05.2013, 15:36
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264709
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mnior
Участник
VRafaelПросто я пытаюсь решить для себя, стоит-ли применять такую конструкциюХе,хе, иногда без неё никуда:
Код: sql
1.
2.
3.
4.
          A
LEFT JOIN B
     JOIN C ON C<->B
            ON B<->A
...
Рейтинг: 0 / 0
20.05.2013, 15:50
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264717
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
GloryВы провели исследования ?
Я не первый день на форуме! И с транзактом работаю довольно плотно, такой синтаксис я-бы не пропустил!
GloryЭто обыкновенный join
Вот это мне и показалось странным! Почему такую "обыкновенную" конструкцию не использует большинство разработчиков?
По моему это удобно в некоторых случаях..
MniorХе,хе, иногда без неё никуда:
Я именно про этот случай. Сейчас и не знаю, как раньше работал без этого )))
...
Рейтинг: 0 / 0
20.05.2013, 15:53
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264731
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
VRafaelЯ не первый день на форуме! И с транзактом работаю довольно плотно, такой синтаксис я-бы не пропустил!
И поэтому вы можете заявлять "его никто не использует" без всяких исследований и цифр ?

VRafaelВот это мне и показалось странным! Почему такую "обыкновенную" конструкцию не использует большинство разработчиков?
Скольких разработчиков, кроме себя, вы опросили ? Сколько из них знало о такой форме записи ?
...
Рейтинг: 0 / 0
20.05.2013, 15:58
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264780
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shakill
Участник
MniorХе,хе, иногда без неё никуда:
Код: sql
1.
2.
3.
4.
          A
LEFT JOIN B
     JOIN C ON C<->B
            ON B<->A


?
Код: sql
1.
2.
3.
           B
      JOIN C ON C<->B
RIGHT JOIN A ON A<->B
...
Рейтинг: 0 / 0
20.05.2013, 16:23
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264801
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
GloryИ поэтому вы можете заявлять "его никто не использует" без всяких исследований и цифр ?
Для этого я и задал вопрос - чтобы провести "исследование", тем более здесь находится целевая аудитория. А по поводу "никто не использует" - это мое личное мнение, основанное на, опять-же, личных наблюдениях. Уверен, что я имею право высказывать свое мнение, в надежде что кто-то более осведомленный (вроде Вас, уважаемый Glory) меня поправит или подскажет где искать правду )))
GloryСкольких разработчиков, кроме себя, вы опросили ? Сколько из них знало о такой форме записи ?
Я работаю разработчиком в крупной компании и на постоянной основе провожу ревью кода многих других, довольно сильных разработчиков T-SQL. На ряду с этим я анализирую много кода на транзакте, накопленного нашей компанией до текущего момента. Никто из них не использует такую конструкцию (во всяком случае на постоянной основе), а один из коллег утверждает что ее лучше не использовать (типа старый синтаксис, никто не юзает эту фичу и т.д.). Это и сподвигло меня задать вопрос здесь, думаю не только мне это будет интересно.
...
Рейтинг: 0 / 0
20.05.2013, 16:35
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264819
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
VRafaelДля этого я и задал вопрос - чтобы провести "исследование", тем более здесь находится целевая аудитория. А по поводу "никто не использует" - это мое личное мнение, основанное на, опять-же, личных наблюдениях. Уверен, что я имею право высказывать свое мнение, в надежде что кто-то более осведомленный (вроде Вас, уважаемый Glory) меня поправит или подскажет где искать правду )))
Высказывание личного мнение правильно сопровождать соответствующим словосочентанием
Например, "по моему личному мнениию, такую форму записи join никто не использует"

VRafaelЯ работаю разработчиком в крупной компании и на постоянной основе провожу ревью кода многих других, довольно сильных разработчиков T-SQL. На ряду с этим я анализирую много кода на транзакте, накопленного нашей компанией до текущего момента. Никто из них не использует такую конструкцию (во всяком случае на постоянной основе), а один из коллег утверждает что ее лучше не использовать (типа старый синтаксис, никто не юзает эту фичу и т.д.). Это и сподвигло меня задать вопрос здесь, думаю не только мне это будет интересно.
А вы сверяете ваши исследования с документированным синтаксисом ?
Ведь для того, чтобы написать какую то языковую конструкцию, нужно о ней по крайней мере знать
Вот вас не смущает такое ?
Код: sql
1.
2.
3.
4.
5.
6.
INNER JOIN
   (SELECT bea.BusinessEntityID, a.City 
    FROM Person.Address AS a
    INNER JOIN Person.BusinessEntityAddress AS bea
    ON a.AddressID = bea.AddressID) AS d
    ON p.BusinessEntityID = d.BusinessEntityID


Здесь тоже два ON идут подряд
...
Рейтинг: 0 / 0
20.05.2013, 16:42
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264880
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
GloryА вы сверяете ваши исследования с документированным синтаксисом ?
Ведь для того, чтобы написать какую то языковую конструкцию, нужно о ней по крайней мере знать
Вот вас не смущает такое ?
Код: sql
1.
2.
3.
4.
5.
6.
INNER JOIN
   (SELECT bea.BusinessEntityID, a.City 
    FROM Person.Address AS a
    INNER JOIN Person.BusinessEntityAddress AS bea
    ON a.AddressID = bea.AddressID) AS d
    ON p.BusinessEntityID = d.BusinessEntityID


Здесь тоже два ON идут подряд
Такая конструкция известна всембольшинству и мной активно используется.
Другое дело - конструкция указанная в топике, я тоже думаю что о ней мало кто знает из разработчиков.
...
Рейтинг: 0 / 0
20.05.2013, 17:06
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264895
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
VRafaelТакая конструкция известна всембольшинству и мной активно используется.
Другое дело - конструкция указанная в топике, я тоже думаю что о ней мало кто знает из разработчиков.
И не говорите - совешенно другая конструкция. Ничего похожего
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
select *
from sysobjects a
inner join syscolumns b 
       join sysindexes c 
       on c.id = b.id 
       on b.id = a.id

select *
from sysobjects a
inner join (syscolumns b 
	join sysindexes c 
        on c.id = b.id) 
        on b.id = a.id

INNER JOIN
   (SELECT bea.BusinessEntityID, a.City 
    FROM Person.Address AS a
    INNER JOIN Person.BusinessEntityAddress AS bea
    ON a.AddressID = bea.AddressID) AS d
    ON p.BusinessEntityID = d.BusinessEntityID
...
Рейтинг: 0 / 0
20.05.2013, 17:13
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264907
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
VRafael,

Это не разный синтаксис, это один и тот же документированный синтаксис. Возможно на примере вам станет понятнее:
Код: sql
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.
28.
29.
30.
31.
32.
declare @t1 table (t1_id int primary key, name varchar(100));
declare @t2 table (t2_id int primary key, name varchar(100), t1_id int);
declare @t3 table (t3_id int primary key, t2_id int);

insert into @t1
values
 (1, 't1_a'), (2, 't1_b');

insert into @t2
values
 (1, 't2_a', 1), (2, 't2_b', 2);

insert into @t3
values
 (1, 1), (2, null);
 
select
 t3.t3_id, t2.name, t1.name
from
 @t3 t3 left join
 @t2 t2 on t2.t2_id = t3.t2_id left join
 @t1 t1 on t1.t1_id = t2.t1_id;

/*Скобки использованы только для улучшения читаемости*/
select
 t3.t3_id, t2.name, t1.name
from
 @t3 t3 left join
 (
  @t2 t2 join
  @t1 t1 on t1.t1_id = t2.t1_id
 ) on t2.t2_id = t3.t2_id;
...
Рейтинг: 0 / 0
20.05.2013, 17:20
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264928
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shakill
Участник
VRafaelДругое дело - конструкция указанная в топике, я тоже думаю что о ней мало кто знает из разработчиков.

можно присмотреться и увидеть, что привычный последовательный список джойнов - это не список, а всего лишь частный случай вложенности
ведь оператор JOIN может соединять только два источника - правый и левый
однако, каждым источником может быть не только таблица/вьюха, но и, в свою очередь, результат вложенного JOIN-а
если вкладывать только левый, то получим привычный частный случай:
Код: sql
1.
 (a join b on ...) join c on ...) join d on ...

а если вкладывать и правый, то увидим общий случай:
Код: sql
1.
(a join b on ...) join (c join d on ...) on ...
...
Рейтинг: 0 / 0
20.05.2013, 17:33
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264948
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
Значит это просто синтаксическое сокращение..
Спасибо Glory, invm, Shakill
Теперь все ясно
...
Рейтинг: 0 / 0
20.05.2013, 17:38
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264970
VRafael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VRafael
Участник
GloryЭто не разный синтаксис, это один и тот же документированный синтаксис
пример дает разные результаты на других данных
Код: sql
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.
28.
29.
30.
31.
32.
declare @t1 table (t1_id int primary key, name varchar(100));
declare @t2 table (t2_id int primary key, name varchar(100), t1_id int);
declare @t3 table (t3_id int primary key, t2_id int);

insert into @t1
values
 (1, 't1_a'), (2, 't1_b');

insert into @t2
values
 (1, 't2_a', 1), (2, 't2_b', 2),(3, 't2_c', 3);;

insert into @t3
values
 (1, 1), (2, null),(3, 3),(4,null);
 
select
 t3.t3_id, t2.name, t1.name
from
 @t3 t3 left join
 @t2 t2 on t2.t2_id = t3.t2_id left join
 @t1 t1 on t1.t1_id = t2.t1_id;

/*Скобки использованы только для улучшения читаемости*/
select
 t3.t3_id, t2.name, t1.name
from
 @t3 t3 left join
 (
  @t2 t2 join
  @t1 t1 on t1.t1_id = t2.t1_id
 ) on t2.t2_id = t3.t2_id;
...
Рейтинг: 0 / 0
20.05.2013, 17:48
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38264985
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cygapb-007
Участник
VRafaelДругое дело - конструкция указанная в топике, я тоже думаю что о ней мало кто знает из разработчиков.Хммм.. А действительно... Спасибо))
Из своего опыта могу сказать следующее: сталкивался с ситуациями, когда в зависимости от кода типа данные надо выбирать либо из одной связки двух таблиц, либо из другой. Всегда соединял по LEFT JOIN все 4 таблицы.

Судя по конструкции из топика, правильнее было бы нечто вроде следующего:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join 
   table11 t11
   inner join table12 t12 on t12<->t11
   on t11<->bt
left join 
   table21 t21
   inner join table22 t22 on t22<->t21
   on t21<->bt

вместо использованного
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join table11 t11 on t11<->bt
left join table12 t12 on t12<->t11
left join table21 t21 on t21<->bt
left join table22 t22 on t22<->t21

так как более четко указывает жесткую зависимость между парами связанных таблиц
2Glory - IMHO:)
...
Рейтинг: 0 / 0
20.05.2013, 17:54
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265003
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mnior
Участник
Shakill?
Код: sql
1.
2.
3.
           B
      JOIN C ON C<->B
RIGHT JOIN A ON A<->B

У нас за использование RIGHT не под делу сажают на кол.
И вообще есть практика описание запросов и ради такой ерунды выворачивать на изнанку? Нет Уж. Лучше уж скобки чем так.
Тем более forece order как себя поведёт?
Код: sql
1.
2.
3.
4.
5.
6.
INNER JOIN
   (SELECT bea.BusinessEntityID, a.City 
    FROM Person.Address AS a
    INNER JOIN Person.BusinessEntityAddress AS bea
    ON a.AddressID = bea.AddressID) AS d
    ON p.BusinessEntityID = d.BusinessEntityID

За такую тоже сажают.
Мол нефиг на ровном месте делать много текста. И вообще лучше без под запросов. Если надо временную вью, та лучше WITH, чем такое.

PS: Подпись тут и далее: IMXO
А то придёт кто-то типа alexeyvg и скажет что у меня какой-то там подход, на который я якобы всех натягиваю насильно, под дулом.
...
Рейтинг: 0 / 0
20.05.2013, 18:02
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265012
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mnior
Участник
Cygapb-007правильнее было бы нечто вроде следующего:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join 
   table11 t11
   inner join table12 t12 on t12<->t11
   on t11<->bt
left join 
   table21 t21
   inner join table22 t22 on t22<->t21
   on t21<->bt

вместо использованного
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join table11 t11 on t11<->bt
left join table12 t12 on t12<->t11
left join table21 t21 on t21<->bt
left join table22 t22 on t22<->t21

Если вы про то что хоть это и разные запросы но оба приемлемы, то я бы писал последнее, ибо если всё зажато FK-ами (или т.п.), то последний не заставляет генератор запросов делать обязательную связку, когда это не нужно.
...
Рейтинг: 0 / 0
20.05.2013, 18:06
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265018
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shakill
Участник
MniorУ нас за использование RIGHT не под делу сажают на кол.
И вообще есть практика описание запросов и ради такой ерунды выворачивать на изнанку? Нет Уж. Лучше уж скобки чем так.

это был вариант в ответ на "без неё никуда". с замечаниями не спорю, хоть на кол у нас и не сажают
...
Рейтинг: 0 / 0
20.05.2013, 18:12
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265034
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cygapb-007
Участник
MniorCygapb-007правильнее было бы нечто вроде следующего:
 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join 
   table11 t11
   inner join table12 t12 on t12<->t11
   on t11<->bt
left join 
   table21 t21
   inner join table22 t22 on t22<->t21
   on t21<->bt

вместо использованного
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select 
   isnull(t11.key,t12.key),
   *
from basetable bt
left join table11 t11 on t11<->bt
left join table12 t12 on t12<->t11
left join table21 t21 on t21<->bt
left join table22 t22 on t22<->t21

Если вы про то что хоть это и разные запросы но оба приемлемы, то я бы писал последнее, ибо если всё зажато FK-ами (или т.п.), то последний не заставляет генератор запросов делать обязательную связку, когда это не нужно.а это уже надо, ятд, смотреть в план выполнения... Потому что пары таблиц жестко связаны между собой по t11.РК (t21.PK), и в первом варианте это подчеркивается в структуре запроса, тогда как во втором - связывание происходит... наверное, по bt тоже?
не готов обсуждать, но первый вариант мне кажется более логичным
опять же IMHO
...
Рейтинг: 0 / 0
20.05.2013, 18:18
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265039
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mnior
Участник
VRafaelНикто из них не использует такую конструкцию (во всяком случае на постоянной основе)Потому что таких задач очень мало. Большинство запросов - звязда.
Но не думаю что вам интересна класиффикация запросов.
VRafael, а один из коллег утверждает что ее лучше не использовать (типа старый синтаксис, никто не юзает эту фичу и т.д.)Брехня. Особенно про старый синтаксис.
Это основа исчисления предикатов, итак в SQL он обрезанный. Спасибо что хоть APPLY добавили.
...
Рейтинг: 0 / 0
20.05.2013, 18:19
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265061
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mnior
Участник
Cygapb-007Mniorпропущено...Если вы про то что хоть это и разные запросы но оба приемлемы, то я бы писал последнее, ибо если всё зажато FK-ами (или т.п.), то последний не заставляет генератор запросов делать обязательную связку, когда это не нужно.а это уже надо, ятд, смотреть в план выполнения ...
не готов обсуждать , но первый вариант мне кажется более логичным
опять же IMHO Эх, зря вы в детали не смотрите. Оболочка ничто - содержимое всё. Дьявол в деталях.
Как же без планов то?!
Cygapb-007,а в первом варианте это подчеркивается в структуре запросаНе надо ничего в запросах подчёркивать. Подчёркивать структуру базы должна, сюрприз, структура базы.
Код должен быть верным, а во вторых удобным для повторного использования. Т.к. в большей части код сущности или понятия обворачивается во вью (и для декларативности и для множественного использования), то там должно поддерживаться механизм "минимизации" (не знаю как точно обозвать).

PS: На тон не обращайте, это не кому лично это к точности/отношению высказанного.
...
Рейтинг: 0 / 0
20.05.2013, 18:28
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265080
Cygapb-007
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cygapb-007
Участник
Mniorпропущено...
Код должен быть верным, а во вторых удобным для повторного использования.Совершенно согласен, и повторюсь - понять структуру первого запроса легче, чем структуру второго, и для этого, сюрприз:)), не требуется разбирать структуру базы. А вопросы оптимизации времени выполнения могут возникнуть только при реально долгом времени выполнения запроса)
И еще раз повторюсь, в проекте был использован второй вариант, потому что не знал (не подумал?) об альтернативных вариантах:)
...
Рейтинг: 0 / 0
20.05.2013, 18:39
| Ответить | Цитировать | Написать  
Вопрос по оператору JOIN
    #38265090
iap
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iap
Участник
Что ж вы тут баяните-то, а?

Глюк или фича при join'е ?
Re: left join - не могу понять, почему запрос не возвращает записи
Интересный синтаксис. JOIN и порядок ON

Поиск: http://www.sql.ru/forum/actualsearch.aspx?search=?????? JOIN&sin=0&bid=1&a=iap&ma=2&dt=-1&s=1&so=1
...
Рейтинг: 0 / 0
20.05.2013, 18:48
| Ответить | Цитировать | Написать  
25 сообщений из 29, страница 1 из 2
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Вопрос по оператору JOIN
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=38265034&tid=1706971]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 24ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 66ms
get tp. blocked users:
 1ms
others: 249ms
total:  382ms
созд. / загр.: 382ms
x
x
Закрыть


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