Selv om dette er teknisk riktig, men praktisk, er dette veldig katastrofalt. Årsaken er at når dataene vokser, blir mye oppsigelser og ubrukelige data lagret. Mange av tidene kan dataene til og med komme i konflikt. En slik ting kan være veldig skadelig for enhver virksomhet. Løsningen lagrer dataene i en database.
Databaseadministrasjonssystem eller DBMS, kort sagt, er en programvare som lar brukerne administrere databasen sin. Når du arbeider med enorme biter av data, brukes en database. Databaseadministrasjonssystem gir deg mange kritiske funksjoner. Upsert er en av disse funksjonene. Upsert, som navnet, indikerer en kombinasjon av to ordoppdatering og innsats. De to første bokstavene er fra oppdatering mens de andre er fire er fra innsats. Upsert tillater datamanipulasjonsspråk (DMLs) forfatter å sette inn en ny rad eller oppdatere en eksisterende rad. Upsert er en atomoperasjon som betyr at det er en enkelttrinns operasjon.
MySQL gir som standard på duplikat nøkkeloppdateringsalternativ for å sette inn, som utfører denne oppgaven. Imidlertid kan andre uttalelser brukes til å fullføre denne oppgaven. Disse inkluderer uttalelser som å ignorere, erstatte eller sette inn.
Du kan utføre Upsert ved hjelp av MySQL på tre måter.
Før vi går videre, vil jeg bruke databasen min for dette eksemplet, og vi skal jobbe i MySQL Workbench. Jeg bruker for øyeblikket versjon 8.0 Community Edition. Navnet på databasen som brukes til denne opplæringen er Sakila. Sakila er en database som inneholder seksten tabeller. Vi vil fokusere på butikkbordet i denne databasen. Denne tabellen inneholder fire attributter og to rader. Attributtbutikken_id er den primære nøkkelen.
La oss se hvordan de ovennevnte måtene påvirker disse dataene.
Oppsatt ved hjelp av Sett inn ignorering
Sett inn ignorerer får MySQL til å ignorere utførelsesfeilene dine når du utfører en innsats. Så hvis du setter inn en ny post med samme primærnøkkel som en av postene som allerede er i tabellen, vil du få en feil. Imidlertid, hvis du utfører denne handlingen ved hjelp av Sett inn ignorering, vil den resulterende feilen bli undertrykt.
Her prøver vi å legge til den nye posten ved hjelp av Standard MySQL Insert -setningen.
Vi mottar følgende feil.
Men når vi utfører den samme funksjonen ved hjelp av Sett inn ignorering, mottar vi ingen feil. I stedet mottar vi følgende advarsel, og MySQL ignorerer denne innsatserklæringen. Denne metoden er gunstig når du legger til enorme mengder nye poster til bordet ditt. Så hvis det er noen duplikater, vil MySQL ignorere dem og vil legge de resterende postene til bordet.
Oppsatt ved hjelp av erstatning:
I noen tilfeller kan det være lurt å oppdatere dine eksisterende poster for å holde dem oppdaterte. Å bruke standardinnsats her vil gi deg en duplikatoppføring for primærnøkkelfeil. I denne situasjonen kan du bruke erstatning for å utføre oppgaven din. Når du bruker erstatt noen to på følgende hendelser, finner sted.
Det er en gammel rekord som samsvarer med denne nye plata. I dette tilfellet fungerer erstatning som en standard innsatserklæring og setter inn den nye posten i tabellen. Den andre saken er at noen tidligere rekord samsvarer med den nye posten som skal legges til. Her erstatt oppdateringer den eksisterende posten.
Oppdateringen gjøres i to trinn. I det første trinnet blir den eksisterende posten slettet. Da blir den nylig oppdaterte posten lagt til akkurat som en standardinnsats. Så den utfører to standardfunksjoner, sletter og setter inn. I vårt tilfelle byttet vi ut den første raden med nyoppdaterte data.
På bildet nedenfor kan du se hvordan meldingen sier “2 rad (er) berørt” mens vi bare erstattet eller oppdaterte verdiene til en enkelt rad. Under denne handlingen ble den første posten slettet, og deretter ble den nye posten satt inn. Derfor sier meldingen: “2 rad (r) berørt.”
Oppsatt ved hjelp av Sett inn ... på duplikatnøkkeloppdatering:
Så langt har vi sett på to kommandoer. Du har kanskje lagt merke til at hver metode hadde sin mangel eller begrensninger hvis du måtte. Ignorer -kommandoen selv om den ignorerte duplikatoppføringen, men den oppdaterte ikke noen poster. Erstatningskommandoen, selv om den oppdaterte, teknisk sett oppdaterte den ikke. Det slettet og satte deretter inn den oppdaterte raden.
Et mer populært og effektivt alternativ enn de to første er ON duplikat nøkkeloppdateringsmetoden. I motsetning til erstatning, som er en destruktiv metode, er denne metoden ikke-destruktiv, noe som betyr at den ikke slipper duplikatrappene først; I stedet oppdaterer det dem direkte. Førstnevnte kan forårsake mange problemer eller feil, og være en destruktiv metode. Avhengig av dine utenlandske nøkkelbegrensninger, kan det forårsake en feil, eller i et verste fall, hvis den utenlandske nøkkelen er satt til å kaskade, kan den slette radene fra den andre koblede tabellen. Dette kan være veldig ødeleggende. Så vi bruker denne ikke-destruktive metoden, da den er mye tryggere.
Vi vil endre postene oppdatert ved å erstatte de opprinnelige verdiene. Denne gangen vil vi bruke ON duplikat nøkkeloppdateringsmetode.
Legg merke til hvordan vi brukte variabler. Disse kan være nyttige fordi du ikke trenger å legge til verdier i uttalelsen, igjen og igjen, og dermed redusere sjansene for feil. Følgende er den oppdaterte tabellen. For å skille den fra den originale tabellen, endret vi Last_upDate -attributtet.
Konklusjon:
Her lærte vi at Upsert er en kombinasjon av to ordoppdatering og innsats. Det fungerer etter følgende prinsipp at hvis den nye raden ikke har noen duplikater, sett den inn, og hvis den har duplikater, utfører den aktuelle funksjonen i henhold til uttalelsen. Det er tre metoder for å utføre oppgang. Hver metode har noen grenser. Den mest populære er ON duplikat nøkkeloppdateringsmetode. Men avhengig av dine krav, kan noen av ovennevnte metoder være til mer nytte for deg. Jeg håper denne opplæringen er nyttig for deg.