SQL: TRA vs < = e > =

Question

In SQL Server 2000 e 2005:

• qual è la differenza tra queste due clausole WHERE ?
• quale dovrei usare su quali scenari?

Query 1:

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

Query 2:

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

(Modifica: il secondo Eventdate era inizialmente mancante, quindi la query era sintatticamente errata)

Answer 1

Sono identici: TRA è una scorciatoia per la sintassi più lunga nella domanda.

Utilizza una sintassi alternativa più lunga in cui TRA non funziona, ad esempio

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

(Nota < anziché < = in seconda condizione.)

Answer 2

Sono uguali.

Una cosa da fare attenzione è che se stai usando questo contro un DATETIME, la corrispondenza per la data di fine sarà l'inizio della giornata:

<= 20/10/2009

non è lo stesso di:

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

( corrisponderebbe a < = 20/10/2009 00: 00: 00.000 )

Answer 3

Sebbene TRA sia facile da leggere e mantenere, raramente ne consiglio l'uso perché è un intervallo chiuso e, come accennato in precedenza, questo può essere un problema con le date, anche senza componenti temporali.

Ad esempio, quando si tratta di dati mensili è spesso comune confrontare le date TRA primo e ultimo , ma in pratica è di solito più facile scrivere dt > = first AND dt < ; next-first (che risolve anche il problema del time part) - poiché determinare last di solito è un passo in più rispetto a determinare next-first (sottraendo un giorno) .

Inoltre, un altro gotcha è che i limiti inferiore e superiore devono essere specificati nell' ordine corretto (ovvero TRA basso E alto ).

Answer 4

In genere, non vi è alcuna differenza: la parola chiave TRA non è supportata su tutte le piattaforme RDBMS, ma se lo è, le due query dovrebbero essere identiche.

Poiché sono identici, non c'è davvero alcuna distinzione in termini di velocità o altro: usa quello che ti sembra più naturale.

Answer 5

Come menzionato da @marc_s, @Cloud, et al. sono sostanzialmente gli stessi per un intervallo chiuso.

Ma qualsiasi valore di tempo frazionario può causare problemi con un intervallo chiuso (maggiore o uguale e minore o uguale ) rispetto a un intervallo semiaperto (maggiore o uguale e minore di ) con un valore finale dopo l'ultimo istante possibile.

Quindi, per evitare che la query debba essere riscritta come:

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

Dato che TRA non funziona per intervalli semiaperti, guardo sempre con attenzione qualsiasi query data / ora che lo utilizza, poiché probabilmente è un errore.

Answer 6

Penso che l'unica differenza sia la quantità di zucchero sintattico su ogni query. TRA è solo un modo semplice per dire esattamente lo stesso della seconda query.

Potrebbe esserci qualche differenza specifica RDBMS di cui non sono a conoscenza, ma non la penso davvero.

Answer 7

Ho una leggera preferenza per TRA perché rende immediatamente chiaro al lettore che stai controllando un campo per un intervallo . Ciò è particolarmente vero se nella tabella sono presenti nomi di campi simili.

Se, diciamo, la nostra tabella ha sia una transazione data che una transizione data , se leggo

transactiondate between ...

So immediatamente che entrambe le estremità del test sono contro questo campo.

Se leggessi

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

Devo dedicare un momento in più per assicurarmi che i due campi siano uguali.

Inoltre, quando una query viene modificata nel tempo, un programmatore sciatto potrebbe separare i due campi. Ho visto molte domande che dicono qualcosa del genere

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

Se provano questo con un TRA , ovviamente, sarà un errore di sintassi e prontamente risolto.

Answer 8

Logicamente non ci sono differenze. Dal punto di vista delle prestazioni ci sono, tipicamente, sulla maggior parte dei DBMS, nessuna differenza.

Answer 9

Vedi eccellente post sul blog da Aaron Bertrand sul perché dovresti cambiare il formato delle stringhe e come vengono gestiti i valori dei limiti nelle query dell'intervallo di date.

Answer 10

Dichiarazione di non responsabilità: tutto ciò che segue è solo aneddotico e attinto direttamente dalla mia esperienza personale. Chiunque si senta in grado di condurre un'analisi più empiricamente rigorosa, può farlo e votare in basso se lo sono. Sono anche consapevole che SQL è un linguaggio dichiarativo e non dovresti considerare come il tuo codice viene elaborato quando lo scrivi, ma, poiché apprezzo il mio tempo, lo faccio.

Ci sono infinite dichiarazioni logicamente equivalenti, ma ne prenderò in considerazione tre (ish).

Caso 1: due confronti in un ordine standard (ordine di valutazione corretto)

  

A > = MinBound AND A < = MaxBound

Caso 2: zucchero sintattico (l'ordine di valutazione non è stato scelto dall'autore)

  

UN TRA MinBound E MaxBound

Caso 3: due confronti in un ordine istruito (ordine di valutazione scelto al momento della scrittura)

  

A > = MinBound AND A > = MaxBound

o

  

A > = MaxBound AND A > = MinBound

Nella mia esperienza, il caso 1 e il caso 2 non presentano differenze coerenti o notevoli in termini di prestazioni in quanto ignoranti del set di dati.

Tuttavia, il caso 3 può migliorare notevolmente i tempi di esecuzione. In particolare, se stai lavorando con un set di dati di grandi dimensioni e hai qualche conoscenza euristica sul fatto che A abbia maggiori probabilità di essere maggiore del MaxBound o inferiore al < strong> MinBound puoi migliorare notevolmente i tempi di esecuzione utilizzando il caso 3 e ordinando i confronti di conseguenza.

Un caso d'uso che ho è di interrogare un grande set di dati storici con date non indicizzate per i record entro un intervallo specifico. Quando scrivo la domanda, avrò una buona idea dell'esistenza o meno di dati PRIMA dell'intervallo specificato o DOPO l'intervallo specificato e posso ordinare i miei confronti di conseguenza. I tempi di esecuzione sono stati dimezzati della metà a seconda delle dimensioni del set di dati, della complessità della query e della quantità di record filtrati dal primo confronto.