ebben a videóban fogunk járni, bár hogyan kell használni az SQL között operátor; megmutatjuk, hogy miért szeretné használni a között operátor, és hogyan lehet elkerülni a buktatókat, ha azt a DATETIME típus.
a két operátor egyenértékű a >= és <= összehasonlító operátorok használatával és kombinációjával, de kompaktabb tartomány-összehasonlítást tesz lehetővé. Miután átnézte ezt a cikket, azt javaslom, hogy nézze meg a következő alapvető SQL Percünket, hogy továbbra is többet tudjon meg az SQL Serverről!
miután megnézte a videót, nézze meg az alábbi mintakódot. Tartalmaztam egy átiratot is, amit használhatsz.
ez egy SQL perc az operátor között!
Üdvözöljük egy másik lényeges SQL percben. Ebben az epizódban, fogunk tanulni, hogyan kell használni a között operátor összehasonlítani egy értéktartomány SQL server lekérdezések.
az operátor közötti értéktartomány összehasonlítására szolgál. Itt van egy példa, ahol használom összehasonlítani egy értéktartományt, amely nagyobb vagy egyenlő, mint 12, kevesebb vagy egyenlő, mint 28. Amikor használom a között operátor, ez inclusive.
tartalmazza azokat a számokat, amelyeket összehasonlítunk a kettő között. A WHERE záradékban a köztes használat közös formája a mező megadása, tehát ebben az esetben “IsoNumericCode”, ez a mező. Aztán az operátorok között; azt mondjuk, hogy azt akarjuk, hogy az “IsoNumericCode” legyen a tartomány között, majd a tartomány között. Azt akarjuk, hogy 12 és 28 között legyen.
lehet, hogy vajon mi ez nézne ki, mint a régi vágású módon segítségével nagyobb, és kisebb, mint és egyenlő. Így nézne ki. Ha ugyanazt a dolgot tennénk, nagyobb és egyenlő és kisebb, mint és egyenlő, akkor lenne hol IsoNumericCode >=12 és IsoNumericCode < = 28.
rendben, tehát menjünk be, hogy lássuk, hogyan néz ki ez az SQL Serverben. A lekérdezésünket az SQL serverbe töltöm be. Itt látható, hogy 12 és 28 között keressük az IsoNumericCode-ot, ugyanarra a sorra kerül, jellemzően így írnák.
SELECT CountryID ,CountryName ,IsoAlpha3Code FROM Application.Countries WHERE IsoNumericCode BETWEEN 12 and 28
engedjék meg, hogy futtassam, és ezt egy kicsit idézzem fel. Láthatjuk, hogy a visszatérési értékek tartománya 12-28. Ha növelném ezt mondjuk 100-ra, azt várnám, hogy több sor jöjjön vissza. Láthatjuk, hogy egészen 100-ig mennek.
most szeretném figyelmeztetni, hogy a rend számít. Ha 100 és 12 között csinálnám, nem kapnék eredményt.
mert ha belegondolsz, azt akarom, hogy a numerikus kódok között legyenek … azt akarom, hogy nagyobb vagy egyenlő legyen 100 – nál, kevesebb vagy egyenlő 12-vel. Semmi sincs a kettő között. Tehát hiba, hogy semmi sem jön vissza. Fontos tehát a rendelés, és fontos, hogy legyen olyan, hogy a két operátor között a legalacsonyabb szám legyen az első. Rendben, térjünk vissza a 12 – re és 28-ra.
egy másik dolog, amit tehetek, a nem operátor használata között. Tehát, ha azt mondom, hogy “nem 12 és 28 között”, akkor azt mondom, hogy hozzuk vissza az országok táblázatának minden sorát, amelynek nincs 12-nél nagyobb vagy egyenlő numerikus kódja, és kevesebb, mint 28.
SELECT CountryID ,CountryName ,IsoAlpha3Code FROM Application.Countries WHERE IsoNumericCode NOT BETWEEN 12 and 28
tehát lényegében ezt a négy sort faragnák ki ebből az eredményből. Futtassuk le. Most már láthatja, hogy 186 Sort kapok.
Ha csak a lekérdezést tettem, korlátozás nélkül, látni fogja, hogy 190 Sort kapok vissza. Tehát ez arra szolgál, hogy megmutassa, hogy ezt a négy sort valóban kivágták. Sőt, ha még egy tesztet akar csinálni, csak annyit mondhatok, hogy 12-28 év között van, és ez mindent visszahozna.
SELECT CountryID ,CountryName ,IsoAlpha3Code FROM Application.Countries WHERE IsoNumericCode NOT BETWEEN 12 and 28 OR IsoNumericCode BETWEEN 12 and 28
tehát ez 190 sort hoz vissza. Tényleg, ez egyfajta értelmetlen abban az értelemben, hogy visszahozza az összes sort.
az összes példánk eddig az egész számmal dolgozott. De között működik sok más adattípus. A karakter adattípusokhoz (VARCHAR) is használhatnánk, és ugyanúgy működne, amíg megvan a kollációs megbízások készlete, minden jól működik.
egy adattípus, bár azt hiszem, óvatosnak kell lennie, a “DateTime” adattípus.
mert a DateTime adattípusban látni fogja, hogy van egy időkomponens a dátumban, és ha csak a napot használjuk, nem pedig az időt, akkor a dátum és az idő alapértelmezés szerint éjfélig tart. Ez tényleg nem kap az összes eredményt úgy gondolja, hogy lenne. Azt hiszem, a legjobb módja annak, hogy megmutassam, mire gondolok.
DECLARE @myTable TABLE(Name varchar(40), ModifyDate DateTime)INSERT INTO @myTable (Name, ModifyDate) VALUES ('Tom', '2017-02-01');INSERT INTO @myTable (Name, ModifyDate) VALUES ('Tom', '2017-02-01 08:23:42');INSERT INTO @myTable (Name, ModifyDate) VALUES ('Tom', '2017-02-01 14:04:02');INSERT INTO @myTable (Name, ModifyDate) VALUES ('Tom', '2017-02-03');INSERT INTO @myTable (Name, ModifyDate) VALUES ('Tom', '2017-02-03 22:32:43');
hozok egy példát, ahol egy táblát deklarálunk, ebben a táblázatban pedig február 1-jétől a 3. – ig fogunk húzni. Amikor ezt lefuttatom, látni fogod, hogy öt sort kapok vissza.
figyeljük meg, hogy vannak idők ezeken, jobb? Ha nem adja meg az időt a dátum, jön vissza a dátum éjfélkor kezdődő. Eddig nagyon jó.
a nagy kérdés az lenne, hogy mi fog történni, majd egy másik lekérdezés itt, ha hozom vissza “ModifyDate” között az 1. és a 3.?
Ha azt mondom, hogy angolul, azt várom mind az öt ilyen, hogy jöjjön vissza. De most azt fogom mondani, hogy nem mind az öt fog visszatérni, mert ez itt, ahol a 3.van rajta, amikor átalakul a DateTime-ra, valójában éjfélkor lesz. Szóval ez lesz csepp, hogy 5. sor. Hadd mutassam meg, mire gondolok itt.
SELECT Name, ModifyDateFROM @myTableWHERE ModifyDate BETWEEN '2017-02-01' AND '2017-02-03'ORDER BY ModifyDate
mint látható, most alapvetően csak négy sort hoz vissza, mert lényegében olyan dátumokat és időket keresünk, amelyek az 1.éjfél és a 3. nagyjából éjfél között vannak.
az egyik módja annak, hogy ezen a környéken dolgozhasson, az éjfél előtti időbe kell helyezni. Szóval csak, hogy … kimegyek a másodpercekre. Tehát most, amikor ezt futtatom, látni fogod, hogy öt sort kapok, mert” 11:59:59 ” másodperc lesz.
SELECT Name, ModifyDateFROM @myTableWHERE ModifyDate BETWEEN '2017-02-01' AND '2017-02-03 23:59:59'ORDER BY ModifyDate
nem számolom a több száz másodpercet stb. Hogy őszinte legyek, úgy érzem, ez elég zűrös. Úgy érzem, ha tényleg szeretné használni között dátumokat ebben az esetben, és azt akarta, hogy minden dátum lehetséges az idejét a 3., a legjobb módja annak, hogy ezt csak használni a 4.
válassza ki a nevet, ModifyDate
FROM @myTable
ahol ModifyDate között “2017-02-01” és “2017-02-04”
rendelés ModifyDate
ebben az esetben között DateTime nem feltétlenül használja ugyanazt a viselkedést, mint gondolnánk, hogy az egészek, mert bár ez befogadó, ez megy éjfélig, ami csak, hogy nanosecond már a 3. Csak viccesnek tűnik. Amikor ezt futtatom, látni fogja, hogy a 3.rész utolsó részéből behúzza azt a dátumot.
tehát ez egy gotcha között DateTime. Szóval tudom, hogy sok ember kerüli a dátumokat és az időt, és csak többet és kevesebbet fognak használni.
tehát felmerül a kérdés; miért használnád a kettő között?
azt hiszem, két oka van annak, hogy miért szeretné használni között. Az első az olvashatóság. A második a karbantarthatóság.
az olvashatóság szempontjából azt értem, hogy ha azt kellene mondanom, hogy “ModifyDate” vagyunk, nagyobb, mint az 1., és a “ModifyDate” kevesebb, mint egyenlő a 4., egy nagyon hosszú lekérdezésben ez nehezen olvasható, mert sok kifejezést kell elkezdeni elemezni, és a logikai logika az utamba kerülhet. Ebben az értelemben, között tűnhet egy kicsit természetesebb olvasni. Azzal a kockázattal jár, hogy félreérti, mit csinál valójában, amint azt a DateTime-vel magyaráztuk.
fenntarthatósági szempontból is, ha be akarok menni, és át kell váltanom, mint a “ModifyDate”, tudom, hogy bejöhetek ide, és két helyen kell megváltoztatnom. Meg kell változtatnom a kifejezés első részét, a második részt pedig hipotetikusan. Ahol, ha csak a kettő között használok, csak egy helyen kell megváltoztatnom.
Ha szeretné tudni, hogy az én veszi-e használni között, vagy nagyobb, vagy kevesebb, mint, én személy szerint nagyobb vagy kevesebb, mint, mert akkor tudom, hogy milyen lépéseket ténylegesen történik. Úgy érzem, van egy kicsit kifejezettebb beleszólásom abba, ami történik, és ettől jobban érzem magam. Nem kell aggódnom, ” ez tényleg működik? Éjfélig tart a dátum?”Minden ilyen feltételezés dolog kimegy az ablakon. Szeretek ott dolgozni, ahol nincs feltételezés a számítógépekben,csak boldogabbnak érzem magam. Én személy szerint nem használja között. De ha tetszik, Azt hiszem, jó használni. Számos SQL nyelvjárásban támogatja, és azt mondom, hajrá. Még egyszer köszönöm, jó napot.