SQLShack (Magyar)

Ez a cikk arról szól, sok különböző SQL adattípusok, hogy használjuk, ha dolgozik SQL Server. Egy gyors áttekintéssel kezdjük, és végigmegyünk néhány dolgon, mint például az adattípusok kategóriái, milyen objektumokkal tudunk dolgozni, valamint hogyan hozhatunk létre saját egyéni adattípusokat.

SQL adattípusok áttekintése

a dolgok elindításához beszéljünk arról, hogy mi az adattípus. Ha meg kellene határoznom, azt mondanám, hogy az adattípus határozza meg az objektumban tárolható adatok típusát, méretét és tartományát., Tehát ez olyan objektumokra vonatkozik, amelyek adattípusokkal rendelkeznek:

• oszlopok
• változók
• kifejezések
• paraméterek

Ez a négy SQL adattípus az objektumok számára a legfontosabb. Oszlopok nyilvánvalóan táblák. Minden alkalommal, amikor létrehozunk egy változót, hozzá kell rendelnünk egy adattípust is. Amellett, hogy ezek, van kifejezések, paraméterek, hogy lezárjuk a listát az objektumok, amelyek fognak tartani az adatokat, ezért meg kell határozni, hogy milyen adatokat fognak tartalmazni.,

továbblépve, nézzük meg az adattípusok három kategóriáját:

• beépített adattípusok
• felhasználó által definiált alias adattípusok
• felhasználó által definiált common language runtime (CLR) adattípusok

az első kategóriáról nem sokat lehet mondani. Ezek olyan adattípusok, amelyekhez mindannyian hozzászoktunk. Az alábbiakban egy diagram, amely felsorolja a jól ismert beépített adattípusok és azok tartományok:

• Megjegyzés: szöveg, Ntext, és a kép SQL adattípus el lesz távolítva egy jövőbeli változata SQL Server. Célszerű elkerülni ezeket az adattípusokat az új fejlesztési munkában., Használja varchar(max), nvarchar(max), és varbinary (max) adattípusok helyett.

ezután megvan, amit az elején említettünk, ezek pedig a felhasználó által definiált álnév adattípusok, amelyek lehetővé teszik számunkra, hogy saját adattípusokat hozzunk létre a fenti beépített lista alapján.

az utolsó kategória a felhasználó által definiált common language runtime (CLR) adattípusok, amelyek lehetővé teszik számunkra, hogy saját adattípusokat hozzunk létre a.NET keretrendszer segítségével., Ez egy kicsit bonyolultabb, mint a fenti, és megköveteli programozási ismeretek építeni egy szerelvény, regisztrálja, hogy a szerelvény belül az SQL Server, hozzon létre egy új SQL adattípus alapján, hogy a szerelvény, majd elkezdhetjük használni az újonnan létrehozott adattípus SQL Server.

SQL adattípusok megfontolások

lépjünk tovább a következő szakaszra, amely alapvetően csak elmélet, de határozottan valami, amire gondolni kell az adatok állandó vagy ideiglenes tárolásakor.,

konverzió

adatbázis-fejlesztőként az egyik leggyakoribb rutin a kód írásakor. A konverzió akkor történik, amikor egy objektum adatait áthelyezik, összehasonlítják vagy egy másik objektum adataival kombinálják. Ezek a konverziók automatikusan megtörténhetnek, amit Implicit konverziónak nevezünk az SQL Serverben vagy manuálisan, amelyet Explicit konverziónak neveznek, ami alapvetően azt jelenti, hogy kódot írunk kifejezetten valamire. Hasznos hüvelykujjszabály, hogy az explicit konverzió mindig jobb, mint az implicit konverzió, mert a kódot olvashatóbbá teszi., Most, hogy konverziókról beszélünk, érdemes megemlíteni azokat a dolgokat is, amelyek segíthetnek nekünk az explicit konverzióban, mint például a CAST and CONVERT funkciók, amelyek az egyik SQL adattípus kifejezésének konvertálására szolgálnak.a

GUID

GUID a globálisan egyedi azonosító rövidítése. Így garantálható az egyediség, és ez az egyik legnagyobb SQL adattípus. A GUID egyetlen hátránya a 16 bájt méretű. Ezért kerülje el a GUID-ok indexeit, amennyire csak lehetséges.

NULL vs., Nem NULL

ha ragaszkodik az SQL Server alapértelmezett értékeihez, ez bizonyos adatintegritási problémákhoz vezethet. Mindig meg kell próbálnia megadni a nullability tulajdonságot, amikor oszlopokat határoz meg a táblákban. Vissza az alapokhoz, A null ismeretlen vagy hiányzó, ami alapvetően azt jelenti, hogy nem 0 vagy üres karakterlánc, és nem tudjuk elvégezni a null összehasonlítást. Nem mondhatjuk, hogy null = null. Ez egy nem tehet. Van egy ansi_nulls nevű tulajdonság, amit beállíthatunk és irányíthatunk null értékekkel.,

ritka oszlopok

Ez a fajta oszlop csak egy rendszeres oszlop az SQL Serverben, kivéve egy olyan tulajdonságot, amely be van állítva, és azt mondja az SQL Servernek, hogy optimalizálja az oszlopot a null tároláshoz.

SQL data type guidelines

mindenekelőtt mindig a megfelelő adattípust használja a feladathoz. Ez sokkal nagyobb, mint a legtöbb ember gondolja. Jelentős hatással lehet a hatékonyságra, a teljesítményre, a tárolásra és az adatbázisok további fejlesztésére.

Ha az első kettőt vesszük, a query optimizer végrehajtási tervet generál attól függően, hogy milyen adattípusokat használnak., Egy nagyon egyszerű példa lehet, ha a bigint adattípust használjuk, ahol a smallint-nos, akkor valószínűleg csak lelassítjuk a lekérdezést. A megfelelő SQL adattípus kiválasztása végül azt eredményezi, hogy a query optimizer hatékonyabban működik.

Ez egy jó ötlet, hogy a dokumentáció magad, mások az adatbázis segítségével adattípusok bemegy az objektumokat. Magától értetődik, de ne elavult adattípusok, mindig ellenőrizze a Microsoft legújabb dokumentációját a híreket, frissítéseket., Ha van egy kis esély arra, hogy nem angol adatokkal fog dolgozni, mindig Unicode adattípusokat használjon. Ezenkívül használja a sysname adattípusokat az Nvarchar adminisztrációs szkriptjeihez.

SQL adattípus példák

ugorjunk át az SSMS-re, és nézzük meg, hogyan tudunk együttműködni az előző szakaszokban említett adattípusokkal. Átnézzük a konverziókat, a ritka oszlopokat és az alias adattípusokat.

Conversion

Cast, Convert and Parse functions convert an expression of one SQL data type to another., Az alábbiakban egy példa lekérdezés, hogy lehet használni a minta ” AdventureWorks “adatbázis ellen” TransactionHistory ” táblázat. Ez megragadta a ” ProductID “és a” TransactionDate”, ahonnan tudjuk használni, hogy a dátum a tranzakció, hogy hogyan conversion works:

itt van az eredményhalmaz a különböző SQL adattípusok:

A Cast függvény ellen TransactionDate átalakítani értékeket egy nvarchar a hossza 30. Ezután a Convert-t használtuk ugyanarra a dologra, de aztán meghatároztuk a 110 formátumot is, amely egy adott dátumstílust ad nekünk., Végül olyan elemzést használtunk, amely lényegében ugyanúgy működik, de rá tudjuk alkalmazni a kultúrát.,nézd meg az eredményt, állítsa be, aztán meglátjuk, mi van:

1. Itt van az az időpont, amikor a tranzakció ahogy ül belül az adatbázis (datetime típusú adat)
2. Itt van, amit úgy néz ki, mint amikor leadott, mint egy szöveges képviselet
3. Konvertáló nem ugyanaz a dolog, de ebben az esetben, vagyunk megjelölve, hogy az adott funkció fordítás kifejezés (110 = hh-nn-nn)
4. Elemzés ebben az esetben, csak lefordítja a kért adatokat adott kultúra (en-US)

a Következő lássuk néhány extra dolog, amit tehetünk, az Elemzési funkció., Parse nagyszerű konvertáló húrok dátumokat, egész számok. Például, ha végrehajtjuk az alábbi Select utasítást, akkor megragadja a 100.000 karakterláncot, és egész számra fordítja:

Itt van az eredmény set:

Most, tegyük fel, hogy meg akarjuk csinálni ugyanezt, de valami oknál fogva, az egész egy karaktert úgy, hogy az SQL Szerver nem tudja átalakítani, hogy egy egész szám:

itt van a hibaüzenet, amit dob:

Msg 9819, Level 16, State 1, Line 2
Error converting string value ’10O. 000′ intt data type using culture”.,

tehát ebben az esetben a Try_Parse használata a szokásos elemzés helyett, mert ha felülről ugyanazt próbáljuk meg, akkor a hiba helyett nulla értéket ad vissza:

1	10o.,000′ as INT) as StringToIntNull;

itt van, amit úgy néz ki, mint:

Ez a módszer azonosítóként használható, ha valami hiba lenne idő előtt más néven védekező kódolás. Próbálkozások lehet alkalmazni a másik két SQL adattípusok is.

ritka oszlopok

ahogy az elején említettem, a ritka oszlopok csökkentik a null térigényeket., So, let’s jump to Object Explorer in our sample database, locate and query BillOfMaterials table to see how this works:

1 2	SELECT * FROM Production.,BillOfMaterials bom;

Észre, hogy van egy csomó a null értékeket belül a ProductAssemblyID, valamint EndDate oszlop:

Ezért azt mondhatjuk, hogy ez a két jelölt, gyér oszlopok., Szóval, az egyik módja annak, hogy változás ez, hogy változtassa meg az ingatlant, a tervező, vagy használja a T-SQL-kód a következő:

1 2 3 4

ALTER TABLE Termelés.BillOfMaterials ALTER COLUMN ProductAssemblyID ADD ritka; GO ALTER TABLE Production.,BillOfMaterials ALTER OSZLOP EndDate HOZZÁ GYÉR; UGRÁS

Parancsok nem fejeződött be sikeresen az első alkalommal, így vesztettem el a fürtözött index (line 7) aztán minden simán ment:

Ha megyünk vissza az Object Explorer, frissítse az BillOfMaterials táblázatot, láthatjuk, hogy azok ketten most megjelölt gyér oszlop:

Szép, igaz. Még egy ügyes dolog a ritka oszlopokban oszlopkészleteknek nevezik., Ez akkor hasznos, ha van egy táblázat, amely tartalmaz egy csomó speciális célú oszlopok, amelyek ritkán használják, mint a példánkban ProductAssemblyID és EndDate oszlopok vagy AddressLine2, MiddleName, stb .. Tehát az oszlopkészlettel az a gondolat, hogy az SQL Server fogja az összes oszlopot, és ad nekünk egy generált XML oszlopot, amely frissíthető. Ez az alkalmazás teljesítménynövekedéséhez vezethet,mivel az SQL Server az oszlopkészlettel dolgozhat, nem pedig az egyes ritka oszlopokkal.,

So, let’s add a column set using those two examples from above using the following command:

1 2 3

ALTER TABLE Production.,BillOfMaterials HOZZÁADÁS SparseColumns XML COLUMN_SET A ALL_SPARSE_COLUMNS; UGRÁS

Szóval, ha megpróbáljuk, hogy adjunk egy oszlopban meghatározott, de a tábla már gyér oszlopok, akkor hiba ki:

Msg 1734, 16-os Szint 1. állapot, Vonal 9
Nem tudja létrehozni a gyér oszlop beállítása ‘SparseColumns’ az asztal ‘BillOfMaterials, mert az asztal már tartalmaz egy vagy több gyér oszlopok. Ritka oszlopkészletet nem lehet hozzáadni egy táblázathoz, ha a táblázat ritka oszlopot tartalmaz.,

Ha valaha is találkozol ezzel, a legegyszerűbb megoldás a ritka oszlopok visszavonása. Ez könnyen elvégezhető a tervezőben. Csak nyisd ki a Tárgy Explorer, válassza ki az oszlop, valamint a oszlop tulajdonságok módosítása a Parse az ingatlant, hogy Nem alábbiak szerint:

Most, ha végre a parancsot még egyszer, hogy sikeres lesz:

A lényeg, hogy ne add gyér oszlopok első – add oszlop meghatározza az első, majd gyér oszlopok. Így nem kell a nehezebb utat választanod., Ami igazán szép ebben, a DML nyilatkozatok, mint a Select, Insert and Update is működik a régi módon hivatkozva az oszlopok külön-külön, vagy meg tudjuk csinálni az oszlop készletek.

felhasználó által definiált SQL adattípusok

zárjuk le a dolgokat egyéni adattípus létrehozásával. Létrehozunk egy alias adattípust, amely egy másik adattípuson alapul. Tegyük fel, hogy szükségünk van az URL-ek tárolására a táblázatunkban, és szeretnénk létrehozni egy tényleges URL-adattípust., All we need to do is execute the code from below:

1 2 3

CREATE TYPE url FROM varchar(2048) NOT NULL GO

URLs are just characters, so the varchar data type is perfect for this., A maximális értéket 2048-ra állítottam be, mert ez a szál, amelyet online találtam, azt állítja, hogy az URL-eket 2048 karakter alatt kell tartania:

láthatjuk ezt az új SQL adattípust, ha az objektum Explorert vezetjük programozhatóság, típusok, felhasználó által definiált adattípusok mappa:

innen elkezdhetjük használni az újonnan létrehozott adattípust., Just an example:

1 2 3

ALTER TABLE Purchasing.Vendor ADD PurchasingWebServiceURL2 url NULL GO

Conclusion

In this article, we learned how to implement SQL data types., Elindítottuk egy áttekintést, hogy megismerkedjünk a beépített adattípusokkal. Aztán beszéltünk néhány dolog, hogy fontolja meg, amikor dolgozik adattípusok és átalakítás segítségével Cast, konvertálni és elemezni funkciók. Mi is beugrott SSMS, ahol megmutattuk, hogyan kell átalakítani egy kifejezés az egyik adattípus egy másik. Áttekintettük, hogyan dolgozhatunk ritka oszlopokkal, majd láttuk, hogyan hozhatunk létre saját egyéni adattípusokat.

remélem, hogy az SQL adattípusokról szóló cikk informatív volt az Ön számára, és köszönöm, hogy elolvasta.,

• Szerző
• Utolsó Hozzászólás

Bojan aka “Boksi”, egy AP diplomás a Technológia összpontosított Hálózatok, illetve az elektronikus technológia a Koppenhágai Iskola, Design, Technológia, egy szoftver elemző a tapasztalat, minőségbiztosítás, szoftver támogatás, a termék evangelizáció, valamint a felhasználói elkötelezettség.,
széles körben írt mind az SQL Shack, mind az ApexSQL megoldási központról, olyan témákról, mint a 4K felbontás és a theming, a hibakezelés az indexstratégiákig, valamint a Teljesítményfigyelés.
Bojan dolgozik ApexSQL Nis, Szerbia szerves részeként a csapat összpontosítva tervezése, fejlesztése, tesztelése céljából a következő generációs adatbázis eszközök, beleértve a MySQL, valamint az SQL Server, mindkettő önálló, eszközök, valamint az integrációs a Visual Studio, SSMS, valamint VSCode.,
további információk Bojan a LinkedIn
összes Megtekintése hozzászólások Bojan Petrovics

Legújabb hozzászólások Bojan Petrovics (minden)

• Visual Studio Kód MySQL, valamint MariaDB fejlesztési – augusztus 13, 2020
• SQL UPDATE szintaxis magyarázta – július 10, 2020
• NÉZET LÉTREHOZÁSA SQL: a Dolgozó indexelt nézetek az SQL Server – Március 24, 2020