SQLShack (Suomi)

SQL Server -kohdistimet ovat yksi yleinen aihe Internetissä . Löydät erilaisia mielipiteitä milloin niitä käytetään ja milloin ei. Tänään puhumme myös niistä ja vastaamme kysymykseen, milloin (ei) niitä tulisi käyttää.

Tietomalli ja yleinen ajatus

Edellisessä artikkelissa SQL-esittely Palvelinsilmukat, puhuimme SQL Server -silmukoista, mutta emme ole käyttäneet tietoja tietokannasta. Se oli outoa, mutta sen pitäisi tulla paljon selvemmäksi nyt. Tänään selitettäessä kohdistimia käytämme tietokannan tietoja osoittamaan, milloin (ei) käyttää kohdistimia. Käytettävä tietomalli on sama, jota käytämme koko sarjassa.

SQL Server tukee 3 eri kohdistinten toteutustavat – Transact-SQL-kohdistimet, API-kohdistimet ja Client-kohdistimet. Tässä artikkelissa keskitymme Transact-SQL-kohdistimiin. Tunnistat ne helposti, koska ne perustuvat DECLARE CURSOR -syntaksiin.

SQL Server Cursor – Johdanto

Ennen kuin siirrymme koodiin ja esimerkkeihin, meidän on selitettävä, mitä SQL Server -kohdistimia ovat.

SQL Server -kohdistin on T-SQL-logiikka, jonka avulla voimme käydä läpi vastaavan kyselyn tuloksen. Tämä antaa meille mahdollisuuden suorittaa toimet peräkkäin – esim. Suorittaa päivityksen yhdellä rivillä.

Joskus tästä voi (näyttää) olevan hyötyä, mutta tietokantojen kanssa työskenneltäessä ei pidä käyttää menettelytapojen ohjelmointimalleja vaan pidä kiinni deklaratiivisesta ohjelmoinnista. Yksi tärkeimmistä syistä on se, että DBMS: t on jo optimoitu suorittamaan toimia tietojoukoille, joten sinun ei pitäisi olla se, joka yrittää olla ”älykkäämpi kuin järjestelmä”.

Se on silti hyvä tietää miten ne toimivat. Jos ei muuta, ehkä tapaat heidät perimäsi koodin kanssa, ja sinun on kirjoitettava logiikka uudelleen. Ja ennen kuin teet mitään, sinun on ymmärrettävä, miten se toimii.

Joten jos tarvitset kohdistimia, sinun on tiedettävä niistä:

  • Kursorit käyttävät muuttujia tallentaakseen silmukan kullekin osalle palautetut arvot. Siksi sinun on ILMOITETTAVA kaikki tarvitsemasi muuttujat
  • Seuraava tehtävä on DECLARE … CURSOR FOR SELECT -kysely, jossa ilmoitetaan kohdistin ja määritetään myös kyseiseen kohdistimeen (täytetään) liittyvä kysely
  • AVAUTAT kohdistimen ja FETCH NEXT kursorista
  • WHILE-silmukassa testataan muuttuja @@ FETCH_STATUS (WHILE @@ FETCH_STATUS = 0). Jos ehto pitää paikkansa, voit kirjoitan silmukan BEGIN … LOPPU-lohko ja suorita lauseita kyseisen lohkon sisällä
  • Kun olet käynyt läpi koko tulosjoukon, poistut silmukasta. SULJE kohdistin ja POISTA se. Kohdistaminen on tärkeää, koska tämä poistaa kohdistimen määritelmän ja vapauttaa käytetyn muistin.

SQL Server -kohdistin – esimerkkejä

Katsotaan nyt kahta kohdistinesimerkkiä. Vaikka ne ovat melko yksinkertaisia, ne selittävät hienosti, kuinka kohdistimet toimivat.

Ensimmäisessä esimerkissä haluamme saada kaikki kaupunkien tunnukset ja nimet yhdessä niihin liittyvien maiden nimien kanssa. Tulostamme komentoja PRINT tulostamaan yhdistelmiä silmukan kullekin kerrokselle.

SQL Server -kohdistimen ja Vaikka silmukka palautti tarkalleen mitä odotimme – kaikkien kaupunkien ja niihin liittyvien maiden tunnukset ja nimet, meillä on tietokannassa.

Tärkeintä tässä mainita on, että voimme yksinkertaisesti palauttaa tämän tulosjoukon. käyttämällä kohdistimen DECLARE-osaan tallennettua alkuperäistä SQL-kyselyä, joten kohdistinta ei tarvinnut.

Menemme vielä yhden esimerkin kanssa. Tällä kertaa kyselemme tietokaaviotietokantaa palauttamaan viisi ensimmäistä taulukkoa taulukon nimen mukaan järjestettyinä. Vaikka tällaisen kyselyn käyttämisellä ei ole paljon järkeä, tämä esimerkki näyttää sinulle:

  • Kuinka tehdä kysely tietomallitietokannasta
  • Kuinka yhdistää muutama komento / käsky, Olemme maininneet edellisissä artikkeleissa (JOS… MUUTA, SILMÄT, CONCAT)

Koodauspuolelta, Haluan korostaa, että tällä kertaa emme ole tulostaneet mitään silmukassa, vaan olemme luoneet merkkijonon CONCAT: lla. Olemme myös käyttäneet IF-käskyä testataksemme, olemmeko ensimmäisellä kierroksella, ja jos on, emme ole lisänneet ””. Muussa tapauksessa lisäämme merkkijonoon ””.

Silmukan jälkeen olemme tulostaneet tulosmerkkijonon, sulkeneet kursorin ja jakaneet sen uudelleen.

Voisimme saavuttaa tämän käyttämällä STRING_AGG-toimintoa. Tämä on saatavana SQL Server 2017: stä alkaen ja vastaa MySQL GROUP_CONCAT -funktiota.

SQL Server-kohdistin – Milloin (ei) käyttää niitä?

Yritän anna objektiivinen vastaus kysymykseen – ”Milloin sinun tulisi käyttää SQL Server -kohdistimia ja milloin ei?” Koska asiat muuttuvat ajan myötä ja parannuksia on tehtävä joko kohdistimiin, joko muihin kohteisiin, jotka niitä ”korvaavat”, on otettava huomioon tämän artikkelin kirjoittamispäivä.Joten, aloitetaan.

Älä käytä kohdistimia:

  • Lähes aina 🙂 Tämä saattaa kuulostaa typerältä, mutta se on totta useimmissa tapauksissa. SQL Server toteuttaa suuren määrän objekteja &, jotka tekevät juuri sen, mitä todennäköisesti yrität ratkaista kohdistimilla. Ennen kuin päätät siirtyä kohdistimen kanssa, varmista, että olet tutkinut asiaa riittävästi johtaaksesi siihen, että kohdistin on ainoa mahdollinen (hyvä) ratkaisu. Sama tarkoittaa silmukoita tietokannoissa. Aikaisemmassa artikkelissa, Intro to SQL Server -silmukat, olemme käyttäneet silmukoita, muttei silmukoita tietojen läpi.

Voit käyttää kohdistimia:

  • Enimmäkseen tietokannan hallintatehtäviin, kuten varmuuskopiointiin, eheystarkistuksiin, hakemistojen uudelleenrakentamiseen
  • Kerran tehtäviä, kun olet varma, että mahdollinen heikko suorituskyky ei vaikuta järjestelmän yleiseen suorituskykyyn.
  • Tallennetun menettelyn kutsuminen muutaman kerran eri parametreilla. Tällöin saat parametrit kohdistimen muuttujista ja soitat silmukan sisällä.

    Tallennetun menettelyn tai muun kohdistimen (tai silmukan) sisällä olevan kyselyn kutsuminen vaikuttaa paljon suorituskykyyn, koska kohdistinsilmukka, suoritat kyselyn / menettelyn alusta alkaen. Jos päätät tehdä niin, sinun tulee olla tietoinen mahdollisista seurauksista.

  • Edellinen vihje tuo meidät viimeiseen luetteloon, kun sinun pitäisi käyttää kohdistimia. Jos olet täysin tietoinen niiden toiminnasta ja olet melko varma, että se ei vaikuta suorituskykyyn, valitse siitä

SQL Server-kohdistin – miksi ihmiset (eivät) käytä niitä ?

Viimeinen kysymys, johon haluaisin vastata, on: Miksi kukaan käyttää kohdistinta? Näen sen näin:

  • Ihmiset, jotka käyttävät niitä kertaluonteisiin töihin tai säännöllisiin toimiin, joissa he eivät vaikuta suorituskykyyn, ovat tekosyynä. Yksi syy on, että tällainen koodi on menettelykoodi, ja jos olet tottunut siihen, se on hyvin luettavissa
  • Toisaalta ne, jotka aloittivat tietokantojen oppimisen ja ovat tottuneet menettelyjen ohjelmointiin, saattavat käytä kohdistimia, koska, kuten mainittiin, ne ovat paljon lähempänä menettelyjen ohjelmointia kuin tietokantoja. Tämä ei ole syy käyttää niitä, koska ainoa tekosyy tässä olisi, että et yksinkertaisesti tiedä toista (oikeaa) tapaa tehdä asiat
  • Kohdistimissa tärkeintä on, että ne ovat hitaita verrattuna SQL-käskyihin, joten sinun tulisi välttää niiden käyttöä, koska ne johtavat ennemmin tai myöhemmin suorituskykyongelmiin (ellet tiedä tarkalleen mitä ja miksi)

I mielestäsi on hyödyllistä, että ymmärrät kohdistimen käsitteen, koska siellä on suuri mahdollisuus, tapaat heidät matkan varrella. Ne olivat suosittuja ennen uusien palvelimien lisäämistä SQL Serveriin. On myös mahdollista, että jatkat työskentelyä järjestelmässä, jossa joku ennen käyttöäsi, ja sinun on jatkettava siellä, missä he pysähtyivät. Ehkä sinun on korvattava kohdistin (menettelykoodi) SQL: llä (deklaratiivinen koodi).

Johtopäätös

Kohdistimista ei ole parempaa päätelmää kuin – älä käytä niitä 🙂 SQL Server on toteuttanut paljon muutoksia, jotka ratkaisevat ongelmat, joita oli vaikea ratkaista aiemmin deklaratiivisella koodilla. Parempi viettää aikaa tutkia ja oppia jotain uutta ja lopuksi tuottaa optimaalinen koodi. Voit tietysti käyttää niitä, jos tiedät miksi teet niin, ja tiedät niihin mahdollisesti liittyvät ongelmat.

Sisällysluettelo

Opi SQL: ää : LUO TIETOKANTA & Luo taulukko-operaatiot

Opi SQL: INSERT INTO TABLE

Opi SQL: Ensisijainen avain

Opi SQL: Vieras avain

Opi SQL: SELECT-käsky

Opi SQL: INNER JOIN vs LEFT JOIN

Opi SQL: SQL-komentosarjat

Opi SQL: Suhteiden tyypit

Opi SQL: Liitä useita taulukoita

Opi SQL: Aggregate Functions

Opi SQL: Kuinka kirjoittaa monimutkainen SELECT-kysely?

Opi SQL: INFORMATION_SCHEMA-tietokanta

Opi SQL: SQL-tietotyypit

Opi SQL: Aseta teoria

Opi SQL: Käyttäjän määrittelemät toiminnot

Opi SQL: Käyttäjän määrittelemät tallennetut menettelyt

Opi SQL: SQL-näkymät

Opi SQL: SQL-käynnistimet

Opi SQL: Harjoittele SQL-kyselyjä

Opi SQL: Esimerkkejä SQL-kyselyistä

Opi SQL: Luo raportti manuaalisesti SQL-kyselyjen avulla

Opi SQL: SQL Serverin päivämäärä- ja aikatoiminnot

Opi SQL: Luo SQL Server -raportit päivämäärä- ja aikatoimintojen käyttäminen

Opi SQL: SQL Server Pivot -taulukot

Opi SQL: SQL Server viedään Exceliin

Opi SQL: johdanto SQL Server -silmukkoihin

Opi SQL: SQL Server -kohdistimet

Opi SQL: SQL: n parhaat käytännöt tietojen poistamiseen ja päivittämiseen

Opi SQL: nimeämiskäytännöt

Opi SQL: SQL-työtehtävät

Opi SQL: Muut kuin Equi-liittymät SQL Serveriin

Opi SQL: SQL Injection

  • Kirjoittaja
  • Viimeisimmät viestit
Emil on tietokannan ammattilainen yli 10 vuoden kokemus kaikesta tietokantoihin liittyvästä. Vuosien varrella hän työskenteli IT- ja finanssialalla ja työskentelee nyt freelancerina.
Hänen aikaisemmat ja nykyiset tehtävänsä vaihtelevat tietokantojen suunnittelusta ja koodauksesta opetukseen, konsultointiin ja tietokantojen kirjoittamiseen. Älä unohda, BI, algoritmien luominen, shakki, filatelia, 2 koiraa, 2 kissaa, 1 vaimo, 1 vauva …
Löydät hänet LinkedInistä
Näytä kaikki Emil Drkusicin viestit

Viimeisimmät kirjoitukset kirjoittanut Emil Drkusic (katso kaikki)
  • Opi SQL: SQL Injection – 2. marraskuuta 2020
  • Opi SQL: Muut kuin Equi-jäsenet SQL Serverissä – 29. syyskuuta 2020
  • Opi SQL: SQL-työtehtävät – 1. syyskuuta 2020

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *