>, >,, = Операторы для условий внутренней регистрации

Мой босс бросил этот код в мою сторону, и мне трудно понять, как работает последний оператор ON внутреннего соединения. Я не думаю, что он полностью это понимает (но он выполняет свою работу). На самом деле просто интересно узнать больше о том, как работает SQL. Спасибо огромное!>, >,, = Операторы для условий внутренней регистрации

Вот заявление о

and (A.Submitted_Date > X.Submitted_Date)))

А вот в запросе

SELECT AA.ID, AA.Submitted_Date as Date_Status  
    FROM Report as AA 
    where AA.Submitted_Date in 
    --START 
     (
     SELECT X.Submitted_Date 
     FROM Report as A 
     inner join 
     --Start Find All Dates Submitted 
     (
     SELECT [ID],[Submitted_Date] 
     FROM Report 
      where not(Submitted_Date is null and Cleared_Date is null) 
      group by ID, Submitted_Date) as X 
     --End Find all Dates Submittd 
    --below is the conditions of the join 


    ON A.ID = X.ID 
    and A.ID= AA.ID 

    --THIS IS THE CONDITION I AM CONFUSED ABOUT!!!! 
    and (A.Submitted_Date > X.Submitted_Date))) 

    group by X.Submitted_Date) 

    and not AA.Submitted_Date is null 
    group by AA.ID, AA.Submitted_Date

Вот пример дат из таблицы А

2012-11-27 00:00:00.000 
2012-11-27 00:00:00.000 
2012-11-27 00:00:00.000 
2012-12-10 00:00:00.000 
2012-11-27 00:00:00.000 
2012-11-27 00:00:00.000 
2012-11-29 00:00:00.000 
2012-12-05 00:00:00.000 
2012-12-12 00:00:00.000

Вот пример дат из таблицы X

2012-11-27 00:00:00.000 
2012-11-29 00:00:00.000 
2012-12-05 00:00:00.000 
2012-12-10 00:00:00.000 
2012-12-12 00:00:00.000

Вот результат до последнего условия

2012-11-27 00:00:00.000 
2012-11-29 00:00:00.000 
2012-12-05 00:00:00.000 
2012-12-10 00:00:00.000 
2012-12-12 00:00:00.000

Вот результат с A.Sub> X.Sub

2012-11-27 00:00:00.000 
2012-11-29 00:00:00.000 
2012-12-05 00:00:00.000 
2012-12-10 00:00:00.000

Я смущен о том, почему эти даты не отображаются. Что сравнивается между A и X? Не будут ли значения в A неизменными как X всегда, поэтому не приводят к окончательным данным? Спасибо за помощь!

источник

2013-03-28 Kyle Copeland

ИМХО было бы яснее, если это условие было в предложении WHERE. Однако я не уверен, что план выполнения будет таким же. –

Думаю, нам нужно больше узнать о вашей таблице отчетов, чтобы полностью ответить на этот вопрос. Можете ли вы обновить свой вопрос, поэтому в образцах данных из X и A также есть Report.ID. У меня есть представление о том, что происходит, но я не могу сказать, не видя идентификаторы, поскольку они являются частью условия соединения. – Fodagus

Результирующие данные относятся к одному идентификатору. Поэтому подумайте об этом наборе результатов как о том, где инструкция внизу, где id = '111'; Спасибо, что пытались помочь! –

Условие соединения делает две вещи. Во-первых, это гарантирует, что x.Submitted_Date не является нулевым. Этот вид прямо противоречит заявлению whre прямо над ним. В этом заявлении Submitted_Date может быть NULL, если Cleared_Date не равно NULL.

Проверка на отсутствие NULL осуществляется просто при использовании. Соединение является внутренним соединением, поэтому сохраняются только строки в x и a. Когда x.Submitted_Date is null, сравнение A.Submitted_Date > X.Submitted_Date оценивается как FALSE (фактически NULL, но NULL эквивалентно FALSE в этом контексте).

Во-вторых, это гарантия того, что есть еще одна запись позже в Report для данного id. Это происходит через одно и то же сравнение: A.Submitted_Date > X.Submitted_Date говорит, что есть более поздняя запись в A, чем X. Условие истинно для всех значений Submitted_Date, за исключением максимального значения.

Итак, вкратце, условия принимают все предоставленные значения даты, за исключением последней даты.

условие может быть эквивалентно:

where AA.Submitted_Date <> (select MAX(x.Submitted_Date) from Report where x.id = AA.id)

Я говорю МАЕ потому что Cleared_Date делает это под вопросом. Но, я думаю, они одинаковы. Предложение where в исходном запросе выполняется, когда x.Submitted_Date не является NULL. Очищенная дата может содержать дополнительные строки, но они должны иметь нулевую дату. Таким образом, он вытаскивает все, кроме самой поданной даты.

Я бы предположил, что логика была еще сложнее, и это «упрощенная» версия, которая может быть упрощена дальше.

источник

2013-03-28 18:00:51

Благодарим вас за ответ Гордон. Не могли бы вы рассказать о том, как он проверяет, есть ли запись позже? И как это гарантирует, что x.submitted_date не является нулевым? Я чувствую, что начинаю понимать лучше! –

Я понимаю, как он избавляется от последней записи. –

Спасибо за объяснение Гордон! Это делает многое понятным. Я действительно ценю твою помощь. –

Было бы лучше, если бы ваши данные включали поле ID. И я полагаю, что идентификатор не уникален. Кроме того, я подозреваю, что ваш выбор образца не идеален для понимания ситуации.

Учитывая эти ограничения по вашему вопросу, я думаю, что вас смущает на самом деле условие A.ID = X.ID. Это заставляет вас думать, что даты будут одинаковыми, и поэтому данных не должно быть.

Если у вас есть отчет таблица:

1 2012-11-27 
1 2012-11-29

то перекрестное соединение создает:

1 2012-11-27 1 2012-11-27 
1 2012-11-27 1 2012-11-29 
1 2012-11-29 1 2012-11-27 
1 2012-11-29 1 2012-11-29

который проходит критерии A.ID = X.ID, а затем A.date> X. дата вернется

1 2012-11-29 1 2012-11-27

изменить: удалить «Запись 2012-11-27 не должна быть частью результата на основе образца». потому что поле даты взято от X, а не от A.

источник

2013-03-28 18:06:09 koriander

Это очень помогает Кориандру! Это имеет смысл, почему он выбрал x.SubDate –

>, >,, = Операторы для условий внутренней регистрации

ответ

Смежные вопросы