SQLShack (Norsk)

Denne artikkelen er om mange forskjellige SQL-datatyper som vi bruker når vi arbeider med SQL Server. Vi vil starte med en rask oversikt og gå gjennom noen ting som kategorier av data typer, hvilke objekter vi kan jobbe med, og hvordan du kan lage våre egne datatyper.

SQL-datatyper oversikt

for Å sparke ting av, la oss snakke om hva som er en datatype. Hvis jeg hadde å definere det, jeg vil si at data type bestemmer type, størrelse og omfanget av data som kan være lagret i et objekt., Så, dette bringer oss til et spørsmål av objekter som har typer data:

• Kolonner
• Variabler
• Uttrykk
• Parametere

Disse fire SQL data typer objekter som er av høyeste betydning. Kolonner er åpenbart for tabeller. Hver gang vi opprette en variabel, må vi også tilordne en datatype til det. I tillegg til disse, har vi uttrykk og parametere for å konkludere med listen av objekter som kommer til å holde data og derfor trenger vi for å angi hva slags data de inneholder.,

du går videre, la oss se de tre kategoriene av typer data:

• Innebygde datatyper
• brukerdefinert alias datatyper
• brukerdefinert common language runtime (CLR) datatyper

Det er ikke mye å si om den første kategorien. Dette er data-typer som vi alle er vant til. Nedenfor er et diagram som viser kjente innebygde datatyper og deres områder:

• Merk: Tekst, Ntext, og Bildet SQL data type vil bli fjernet i en fremtidig versjon av SQL Server. Det er lurt å unngå å bruke disse data typer i ny utvikling-arbeid., Bruk varchar(max), nvarchar(max) og varbinary(max) datatyper i stedet.

Neste, har vi det vi nevnte i begynnelsen, og de er bruker-definert alias typer data, som gir oss mulighet å skape våre egne data typer som er basert på den innebygde listen ovenfor.

Den siste kategorien er brukerdefinerte common language runtime (CLR) datatyper som gir oss mulighet å skape våre egne data-typer ved hjelp av den .NET Framework., Dette er litt mer komplisert enn de ovennevnte, og krever programmering ferdigheter til å bygge en sammenstilling registrere at montering på innsiden av SQL Server, kan du opprette en ny SQL-data-type basert på at montering og da kan vi begynne å bruke den nyopprettede datatype i SQL Server.

SQL-datatyper hensyn

La oss gå videre til neste delen som er utgangspunktet bare teori, men definitivt noe som du bør tenke på når du lagrer data enten permanent eller midlertidig.,

Konvertering

Som en database utbygger, en av de mest vanlige rutiner når du skriver kode er konvertering. Konvertering skjer når data fra et objekt er flyttet, sammenlignet med eller kombinert med data fra et annet objekt. Disse konverteringene kan skje automatisk, det vi kaller Implisitt konvertering i SQL Server eller manuelt som er kjent som en Eksplisitt konvertering som i utgangspunktet betyr å skrive kode spesielt å gjøre noe. En nyttig tommelfingerregel er at en eksplisitt konvertering er alltid bedre enn implisitt konvertering fordi det gjør koden mer lesbar., Nå som vi snakker om konverteringer, også verdt å nevne er ting som kan hjelpe oss med eksplisitt konvertering som STØPT og KONVERTERE funksjoner som brukes til å konvertere et uttrykk for en SQL data type til en annen.

GUID

GUIDEN er et akronym for Globalt Unik Identifikator. Det er en måte å garantere unikt, og det er en av de største SQL datatyper. Den eneste ulempen av GUIDEN er 16 bytes. Derfor, unngå indekser på Guidene så mye som mulig.

NULL vs., IKKE NULL

Hvis du holder deg med SQL Server standarder, som kan føre til noen data integritet problemer. Du bør alltid prøve å angi nullability holderen når du definerer kolonnene i tabellene. Tilbake til det grunnleggende, null betyr ukjent eller mangler som i utgangspunktet betyr at det ikke er 0 eller en tom streng, og vi kan ikke gjøre null sammenligningen. Vi kan ikke si null = null. Dette er en ikke kan gjøre. Det er en egenskap som kalles ANSI_NULLS at vi kan stille inn og styre denne sammenligningen med null-verdier.,

Sparsom kolonner

Denne typen kolonnen er bare en vanlig kolonne i SQL Server bortsett fra en eiendom som er satt til på, og det forteller SQL-Server for å optimalisere denne kolonnen for null-lagring.

SQL data type retningslinjene

Først av alt, må du alltid bruke riktig datatype for jobben. Dette er et mye større enn de fleste tror. Det kan ha en betydelig innvirkning på effektivitet, ytelse, lagring og videre database utvikling.

Hvis vi tar de to første, query optimizer kommer til å generere en gjennomføringsplan avhengig av hvilke datatyper som er brukt., Et veldig enkelt eksempel kan være hvis vi bruker bigint datatype der vi kan være med smallint – vel, da er vi mest sannsynlig bare bremse ned søket. Å velge riktig SQL data type vil til slutt resultere i query optimizer å jobbe mer effektivt.

Det en god idé å gi dokumentasjon for deg selv og andre ved hjelp av database for data typer kommer inn i objekter. Det går uten å si, men unngå ugyldige data typer, sjekk alltid Microsofts nyeste dokumentasjonen for nyheter og oppdateringer., Hvis det er en liten sjanse for at du kommer til å arbeide med ikke-norsk data, må du alltid bruke Unicode-data typer. Videre, kan du bruke sysname typer data, for den administrative skript over nvarchar.

SQL data type eksempler

La oss hoppe over til SSMS og se på hvordan vi kan arbeide med noen av de typer data, som nevnt i forrige avsnitt. Vi vil gå gjennom konverteringer, spredte kolonner, og alias datatyper.

Konvertering

Støpt, Konvertere og Analysere funksjoner konvertere et uttrykk for en SQL data type til en annen., Nedenfor er et eksempel på spørring som kan brukes på en prøve «AdventureWorks» database mot «TransactionHistory» tabellen. Det er å ta tak i «ProductID» og «TransactionDate» som vi kan bruke som dato for transaksjonen for å se hvordan konverteringen fungerer:

Her er resultatet sett av ulike SQL-datatyper:

Vi har brukt Kastet funksjon mot TransactionDate å konvertere verdier til en nvarchar til en lengde på 30. Neste, vi brukte Konvertere til å gjøre det samme, men da har vi også angitt format 110, noe som gir oss en bestemt dato stil., Sist brukte vi Analysere som i hovedsak virker på samme måte, men vi kan bruke kultur til det.,se på resultatet stille og se hva vi fikk:

1. Her har vi dato og klokkeslett for den transaksjonen som det ligger innenfor database (datetime data type)
2. Her er hvordan det ser ut når vi kastet det som en tekst representasjon
3. Konvertering gjør det samme, men i dette tilfellet, vi er spesifisere hvordan Konvertere funksjon vil oversette uttrykket (110 = mm-dd-åååå)
4. Parsing i dette tilfellet, bare oversetter forespurte data ved hjelp av spesifikke kultur (en-US)

Neste, la oss se på noen ekstra ting som vi kan gjøre med det Parse funksjon., Parse er flott med konvertering strenger å datoer og heltall. For eksempel, hvis vi gjennomfører de Select-setning under, vil det ta strengen 100.000 og slå den inn i et heltall:

Her er resultat:

Nå, la oss si at vi ønsker å gjøre det samme igjen, men for noen grunn, heltall som har en karakter på det at SQL-Serveren kan ikke konvertere til et heltall:

Her er det feil melding at det kaster:

Msg 9819 Nivå 16, Tilstand 1, Linje 2
Feil konverterer string verdi ’10O.000′ i datatype int bruk av kultur «.,

Så, hva kan vi gjøre i dette tilfellet er å bruke Try_Parse i stedet for vanlig Analysere fordi hvis vi prøver på det samme fra ovenfor, vil det gå tilbake en null-verdi » i stedet for feilmeldingen:

Her er hva det ser ut som:

Denne metoden kan brukes som en identifikator hvis noe skulle feil ut i forkant av tid AKA defensive koding. Prøver kan brukes for de to andre SQL-datatyper, i tillegg.

Sparsom kolonner

Som jeg nevnte i begynnelsen, spredte kolonner redusere null kravene til plass., So, let’s jump to Object Explorer in our sample database, locate and query BillOfMaterials table to see how this works:

legg Merke til at det er mange av null-verdier i ProductAssemblyID og Sluttdato kolonner:

Derfor, kan vi si at disse to er gode kandidater for sparsom kolonner., Så, en måte å endre dette på er å bare endre eiendom i designer eller vi kan gjøre det ved hjelp av T-SQL-kode fra nedenfor:

Kommandoer ble ikke fullført første gang, så jeg måtte miste samlet indeks (linje 7), og deretter gikk alt glatt:

Hvis vi går tilbake til Objekt Explorer, kan du oppdatere BillOfMaterials tabellen kan vi se at de to er nå markert som sparsom kolonner:

Nice, rett. En mer ryddig ting om sparsom kolonner kalles kolonne angir., Dette er nyttig i en situasjon når vi har en tabell som inneholder en haug av spesielle formål kolonner som brukes sjelden som i vårt eksempel ProductAssemblyID og Sluttdato kolonner eller AddressLine2, MiddleName, etc. Så, ideen med kolonnen sett er at SQL Server vil ta alle de kolonner og gi oss en genererte XML-kolonne som oppdateres. Dette kan føre til en økning i ytelse av programmet fordi SQL Server kan arbeide med kolonnen angir snarere enn med hver spredt kolonne individuelt.,

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

Så, hvis vi prøver å legge til en kolonne, men vårt bord allerede har en sparsom kolonner, vil det feil ut:

Msg 1734, Nivå 16, Staten 1, Linje 9
du kan Ikke opprette den sparsomme kolonne angir «SparseColumns’ i tabellen ‘BillOfMaterials’ fordi tabellen allerede inneholder en eller flere spredte kolonner. En spredt kolonne sett kan ikke legges til i en tabell hvis tabellen inneholder en spredt kolonne.,

Hvis du noensinne kommer over dette, er den enkleste løsningen er å angre sparsom kolonner. Dette kan enkelt gjøres i designer. Bare åpne det opp fra Object Explorer, velger du kolonnen som du trenger, og i kolonnen egenskaper endrer den Er egenskapen til å Analysere Ingen som vist nedenfor:

Nå, hvis vi utføre kommandoen en gang til, det skal bli vellykket:

Den nederste linjen her, ikke legge sparsom kolonner første – legg til-kolonnen angir først, og deretter spredte kolonner. På den måten trenger du ikke å gjøre det på den harde måten., Hva er egentlig ryddig om dette, er vår DML-uttrykk, for eksempel Select, Insert og Update kan fortsatt fungere på den gamle måten ved å referere til kolonner individuelt eller vi kan gjøre det ved hjelp av kolonnen angir.

brukerdefinert SQL datatyper

La oss bryte opp ting med å lage en egendefinert datatype. Vi kommer til å opprette et alias data type som er basert på en annen datatype. La oss bare si at vi har et behov for lagring av Nettadresser i bordet vårt, og vi ønsker å skape en faktisk URL datatype., All we need to do is execute the code from below:

URLs are just characters, so the varchar data type is perfect for this., Jeg har satt maks verdi til 2048 på grunn av denne tråden at jeg har funnet online som sier at du bør holde Nettadresser under 2048 tegn:

Vi kan se det nye SQL data type hvis vi hodet over Object Explorer, under Programmatisk, Typer, brukerdefinerte Datatyper, mappe:

her Fra, vi kan begynne å bruke den nyopprettede datatype., Just an example:

Conclusion

In this article, we learned how to implement SQL data types., Vi sparket i gang med en oversikt, bare for å bli kjent med noen av de innebygde datatyper. Deretter snakket vi om noen ting å vurdere når du arbeider med data typer og konvertering ved hjelp av Støpejern, Konvertere og Analysere funksjoner. Vi har også hoppet inn SSMS hvor vi viste hvordan å konvertere et uttrykk for en datatype til en annen. Vi gikk gjennom hvordan du arbeider med sparsom kolonner, og da vi så også hvordan du kan lage våre egne datatyper.

jeg håper denne artikkelen på SQL-datatyper har vært informativt for deg, og jeg takker for at du leser det.,

• Forfatter
• Siste Innlegg

Bojan aka «Boksi», en AP utdannet i IT-Teknologi fokusert på Nettverk og elektronisk teknologi fra København School of Design og Teknologi, er en programvare som analytiker med erfaring i kvalitetssikring av programvare, et produkt evangelisering, og brukerens engasjement.,
Han har skrevet mye på både SQL Shack og ApexSQL Solution Center du kan, på emner som varierer fra klient teknologier som 4K-oppløsning og tematisere, feil håndtering for å indeks strategier, og overvåking av ytelse.
Bojan fungerer på ApexSQL i Nis i Serbia som en integrert del av team med fokus på å designe, utvikle og teste den neste generasjonen av database verktøy, inkludert MySQL og SQL Server, og både frittstående verktøy og integrasjoner inn i Visual Studio, SSMS, og VSCode.,
Se mer om Bojan på LinkedIn
Vis alle innlegg av Bojan Petrovic

Siste innlegg av Bojan Petrovic (se alle)

• Visual Studio Koden for MySQL og MariaDB utvikling – August 13, 2020
• OPPDATERINGEN for SQL syntaks forklart – 10. juli 2020
• CREATE VIEW SQL: å Arbeide med indeksert utsikt i SQL Server – Mars 24, 2020