SQL:МЕЖДУ vs <= и >=

StackOverflow https://stackoverflow.com/questions/1630239

Вопрос

В SQL Server 2000 и 2005:

  • в чем разница между этими двумя WHERE статьи?
  • какой из них мне следует использовать в каких сценариях?

Запрос 1:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate BETWEEN '10/15/2009' AND '10/18/2009'

Запрос 2:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate >='10/15/2009'
  AND EventDate <='10/18/2009'

(Редактировать:вторая дата события изначально отсутствовала, поэтому запрос был синтаксически неправильным)

Это было полезно?

Решение

Они идентичны: BETWEEN это сокращение более длинного синтаксиса в вопросе.

Используйте альтернативный более длинный синтаксис, где BETWEEN не работает, например

Select EventId,EventName from EventMaster
where EventDate >= '10/15/2009' and EventDate < '10/18/2009'

(Примечание < скорее, чем <= во втором состоянии.)

Другие советы

Они одинаковые.

Следует быть осторожным: если вы используете это для DATETIME, совпадением конечной даты будет начало дня:

<= 20/10/2009

это не то же самое, что:

<= 20/10/2009 23:59:59

(это бы матч против <= 20/10/2009 00:00:00.000)

Хотя BETWEEN легко читать и поддерживать, я редко рекомендую его использовать, поскольку это закрытый интервал, и, как упоминалось ранее, это может быть проблемой с датами - даже без компонентов времени.

Например, при работе с ежемесячными данными часто сравнивают даты. BETWEEN first AND last, но на практике это обычно проще написать dt >= first AND dt < next-first (что также решает проблему части времени) - с момента определения last обычно на один шаг дольше, чем определение next-first (путем вычитания суток).

Кроме того, еще одна ошибка заключается в том, что в файле необходимо указывать нижнюю и верхнюю границы. правильный заказ (т.е. BETWEEN low AND high).

Обычно разницы нет, т. BETWEEN Ключевое слово не поддерживается на всех платформах СУБД, но если оно поддерживается, то два запроса должны быть идентичны.

Поскольку они идентичны, на самом деле нет никакой разницы в скорости или чем-либо еще — используйте тот, который кажется вам более естественным.

Как упоминалось @marc_s, @Cloud и др.они в основном одинаковы для закрытого диапазона.

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

Поэтому, чтобы избежать этого, запрос следует переписать так:

SELECT EventId, EventName
  FROM EventMaster
 WHERE (EventDate >= '2009-10-15' AND
        EventDate <  '2009-10-19')    /* <<<== 19th, not 18th */

С BETWEEN не работает для полуоткрытых интервалов. Я всегда внимательно смотрю на любой запрос даты/времени, который его использует, поскольку это, вероятно, ошибка.

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

Возможно, есть какая-то специфическая разница в СУРБД, о которой я не знаю, но я так не думаю.

У меня есть небольшое предпочтение BETWEEN потому что это сразу дает читателю понять, что вы проверяете одно поле для диапазона.Это особенно актуально, если в вашей таблице есть похожие имена полей.

Если, скажем, в нашей таблице есть оба transactiondate и transitiondate, если я прочитаю

transactiondate between ...

Я сразу понимаю, что оба конца теста направлены против этого одного поля.

Если я прочитаю

transactiondate>='2009-04-17' and transactiondate<='2009-04-22'

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

Кроме того, поскольку запрос со временем редактируется, небрежный программист может разделить два поля.Я видел множество запросов, которые говорят что-то вроде

where transactiondate>='2009-04-17'
  and salestype='A'
  and customernumber=customer.idnumber
  and transactiondate<='2009-04-22'

Если они попытаются сделать это с BETWEEN, Конечно, это будет синтаксическая ошибка и ее оперативно исправят.

По логике разницы вообще нет.С точки зрения производительности, как правило, в большинстве СУБД нет никакой разницы.

Видеть это отличный пост в блоге от Аарон Бертран о том, почему вам следует изменить формат строки и как граничные значения обрабатываются в запросах диапазона дат.

Отказ от ответственности:Все, что ниже, является лишь анекдотическим и взято непосредственно из моего личного опыта.Любой, кто чувствует себя готовым к проведению более строгого эмпирического анализа, может его провести и проголосовать против, если я согласен.Я также знаю, что SQL — это декларативный язык, и вам не нужно учитывать, КАК обрабатывается ваш код, когда вы его пишете, но, поскольку я ценю свое время, я это делаю.

Существует бесконечное количество логически эквивалентных утверждений, но я рассмотрю три (около).

Дело 1:Два сравнения в стандартном порядке (фиксированный порядок оценки)

A >= MinBound И A <= MaxBound

Случай 2:Синтаксический сахар (порядок оценки автором не выбран)

МЕЖДУ MinBound И MaxBound

Случай 3:Два сравнения в определенном порядке (порядок оценки выбирается во время записи)

A >= MinBound И A >= MaxBound

Или

A >= MaxBound И A >= MinBound

По моему опыту, случаи 1 и 2 не имеют каких-либо существенных или заметных различий в производительности, поскольку они не учитывают набор данных.

Однако вариант 3 может значительно сократить время выполнения.В частности, если вы работаете с большим набором данных и обладаете некоторыми эвристическими знаниями о том, А скорее всего, будет больше, чем Максбаунд или меньше, чем MinBound вы можете заметно сократить время выполнения, используя вариант 3 и соответствующим образом упорядочив сравнения.

У меня есть один вариант использования — запрос большого набора исторических данных с неиндексированными датами для записей в пределах определенного интервала.При написании запроса я буду иметь хорошее представление о том, существует ли больше данных ДО указанного интервала или ПОСЛЕ указанного интервала, и смогу соответствующим образом упорядочить свои сравнения.Время выполнения сократилось почти вдвое в зависимости от размера набора данных, сложности запроса и количества записей, отфильтрованных при первом сравнении.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top