|
|
Publisert på 15.03.2019 22:45:21
|
|
|
|
forord
Forrige gang skulle jeg organisere alt det grunnleggende innholdet i SQL, men jeg oppdaget at klokken begynte å gå før jeg visste ordet av det. Denne artikkelen fortsetter nedenfor.
Tekst
Først, la oss lage tabellene vi trenger
La oss kjøre en SQL-setning først
Denne koden trekker fra saldoen 0001 med 1000 og saldoen 0002 med 1000. Men vi la til begrensninger da vi bygde tabellen, og balansen må være større enn eller lik 10.
Resultatene er som følger:
Så denne kodeutførelsesfeilen: "UPDATE-setningen er i konflikt med CHECK-begrensningen "CH_balance". Konflikten oppstår i databasen "DemoDb" med tabellen "dbo. Bank», kolonnen 'saldo'。” 。 Hvis én setning er feil, er det om den andre setningen har blitt utført med suksess.
Søkeresultatene er som følger:
Vi vil se at en annen SQL-setning ikke har feil, men fortsatt ikke committer med suksess. Her er hva vi vil avsløre for deg.
#Transaksjoner
Hva er en transaksjon?
Strengt tatt, hvis en operasjon tilfredsstiller atomitet, persistens, isolasjon og konsistens, kalles operasjonen en transaksjon.
Send automatisk inn transaksjoner: i SQL Server. Som standard er hver SQL-setning en transaksjon.
Vis transaksjoner: Hver transaksjon starter eksplisitt med en BEGIN TRANSACTION-setning og avsluttes eksplisitt med en COMMIT- eller ROLLBACK-setning.
Demoen vi nettopp nevnte ovenfor endte med Rollback, så SQL-kjøringen trer ikke i kraft. Dataene ble ikke endret med suksess.
I faktisk utvikling og applikasjon setter vi vanligvis opp et lag med transaksjoner utenfor ikke-spørringssetningen for å sikre integritet og konsistens i dataene i henhold til faktiske behov. Enten gjør alt, eller så gjør du ikke alt.
Det er to systemvariabler som logger den feilaktige SQL-en. - @@rowcount returnerer antall berørte linjer, returnerer @@error feil koding
La oss bruke disse to systemvariablene for å avgjøre om det er en feil i SQL og utføre de to ovennevnte SQL-setningene.
#Lagrede prosedyrer
Det vil si: Kapsl inn en prosess som utføres (som kan være kompleks) i et navn, og bruk deretter det navnet til å utføre prosessen.
> Parameterløse lagrede prosedyrer
>Lagrede prosedyrer med parametere
>Lagret prosedyre med returverdi
Prøv å fange i databasen
Det finnes også lagrede prosedyrer med standardparametere, som ble nevnt i forrige artikkel om paginering.
Epilog
Lagrede prosedyrer brukes mer i våre faktiske prosjekter, mange eldgamle systemer, forretningslogikk er skrevet i lagrede prosedyrer, og folkene bak vedlikeholder den, og de vil bare hamre hundens hode foran seg på minutter. Generelt skrives forretningslogikken i koden, men antall ganger dataene leses fra databasen, og forretningslogikken skrives i lagringsprosessen. I fjor ble en svært kompleks streng av forretningslogikk i selskapets prosjekt flyttet til lagringsprosessen, noe som økte hastigheten med dusinvis av ganger. Selvfølgelig behandles spesielle omstendigheter spesielt. Den spesifikke bruken avhenger av den faktiske situasjonen.
(Merk: Innholdet ovenfor er studienotatene for året, hvis det er noe upassende, vennligst rett det!) ）
|
Foregående:Jeg føler for kundeservicesystemet til store selskaperNeste:Video av Andale HCNP og HCIE
|
