Lærer du om databaseadministratorer? I så fall må du informere deg selv om datatyper i MySQL, en av de beste og mest brukte i verden. Ikke gå glipp av muligheten!.
Datatyper i MySQL
Hver gang vi trenger å lage en tabell som tjener til å lagre data for et program, må vi vite hvordan vi kan identifisere hvilken type data vi bruker for å lagre alt vi trenger for å arkivere. Vi kan velge mellom tre: numeriske data, strenger (alfanumerisk) og datoer og klokkeslett.
I disse feltene i MYSQL -tabellene har vi muligheten til å velge mellom tre typer innhold, og selv om det virker åpenbart, bestemme hvor vi skal sende dataene våre, hvilken type gruppe lagringen vil tilhøre, her har vi et eksempel for å sette oss selv i kontekst: ja vi trenger et felt som vi kan lagre alderen til en person med, så ville det være et numerisk datafelt.
Men før jeg fortsetter å forklare, vet du hva MySQL er? Det er kjent som en av de mest brukte open source -databaseadministratorene i verden. For at vi skal få en ide om hvor populært det er, vil vi fortelle deg at: WordPress er leder for forskjellige typer innhold, som har eksistert siden 2003, og at rundt 55% til 60% av nettsidene som finnes, er laget takket være dette, og den bruker MySQL som en database, så dette beviser hvor nyttig det kan være og omfanget det har.
MySQL tilhører Oracle Corporation -selskapet, som hadde ansvaret for å kjøpe det i 2010. Denne lederen har flere bruksområder, for eksempel: praksis, utførelse av installasjoner, modifisering av nettsider, lesing av data, blant andre.
Denne driveren kan enkelt lastes ned og har flere versjoner avhengig av Windows du bruker, på samme måte er det veldig enkelt å installere den.
De aller fleste databasedrivere brukes gjennom et programmeringsspråk. La oss si at for eksempel informasjonen vi har på datamaskinene våre er tilgjengelig i databasen, men når vi trenger å se og administrere den, bruker den et programmeringsspråk; Når det gjelder MySQL, er det ledsaget av php, som er kjent som et webutviklingsspråk, det samme som WordPress er utviklet med.
Vi antar at vi kan anbefale for hastighet å laste ned XAMPP -verktøyet, som er tilgjengelig for forskjellige versjoner av Windows. XAMPP kommer med en serie komponenter, blant dem har vi:
- Apache: Dette ville være en webserver.
- PHP: Nettutviklingsspråket.
- Fillezilla: Han har ansvaret for å mobilisere filene.
- Merkur: Det er e -postserveren som har til hensikt å gjøre testene.
- MySQL: Som vi nevnte tidligere, er det databaseserveren.
Etter at du har installert XAMPP, vil du kunne nyte alle disse komponentene, inkludert MySQL, som du kan starte direkte og koble til det grafiske grensesnittet, og derfor er XAMPP ekstremt nyttig, i tillegg til å ha de andre komponentene.
Da vi hadde alt dette klart, ønsket vi å forklare at innenfor våre alternativer for typer tabeller for å lagre dataene våre, og når vi snakker om det numeriske datafeltet, har vi andre typer innenfor dette samme, og vi må vite hvilke som ville være de beste, som ville gi oss muligheten til å forbruke mindre fysisk lagringsplass og vil gi oss muligheten til data som vi håper å lagre i det feltet. Den eneste måten å forstå disse spørsmålene er de forskjellige typer data som MySQL gir oss. Nedenfor gir vi den informasjonen for å forstå den mest hensiktsmessige bruken av hver gruppe.
Vi inviterer deg til å se et intensivt kurs om datatyper i MySQL og alt du trenger å vite om det, i videoen nedenfor. Ikke gå glipp av muligheten til å lære!:
Numeriske data
Forskjellen vi kan finne mellom en type data og en annen i MySQL er ganske enkelt verdiområdet det kan inneholde. Innenfor de numeriske dataene må vi se at vi kan skille mellom to store grener: heltall og desimaler; Nå vil vi forklare hvilke typer numeriske data vi kan ha i henhold til situasjonen som presenteres for oss og hva vi trenger:
Numeriske heltall
Det første vi vil forklare på dette tidspunktet er at alternativene vi har for å lagre denne typen data vil være aldre, mengder og størrelser uten desimaler. Vi vil også presentere et eksempel for bedre å forstå hvilken type data vi bør velge for hvert felt:
Vi presenterer TINYINT, en datatype som lar oss lagre en maksimalverdi på 127. Så hvis vi trenger å definere et felt for brukernes alder, er dette den vi kan bruke, fordi det normale aldersområdet er innenfor dette tallet , og med mindre vi lever i det bibelske gamle testamentets tid, har ingen biologisk overgått dette tallet; Så nei, denne typen data lar oss ikke lagre 567, for eksempel ikke engang 128, hvis grensen når 127.
Nå, hvis vi ønsker å definere et felt for en identifikator for et stort marked for å selge tusenvis av forskjellige og varierte ting, ville dette endres eksponensielt, tydelig at TINYINT ikke lenger tjener oss, i tillegg til dette bør vi vite nøyaktig mengden varer den selger, men ikke bare med det vi har for øyeblikket, men prøver å gjøre en spådom for vår nærmeste fremtid, på denne måten blir ikke lagringssystemet vårt raskt foreldet.
Vi kan bruke noe som SMALLINT som lar oss nummerere opptil 32,000 5 artikler, men hvis vi endrer eksemplet og går fra et marked til et ID -felt som skal brukes til et kundetabell for et telefonselskap med 200 millioner brukere, kan vi kunne ikke lenger ha SMALLINT, men noen andre som MEDIUMINT, og vi fortsetter, i tilfelle selskapet vårt hadde XNUMX millioner kunder, bør vi bruke et felt av typen INT. Problemet endres i tilfelle å bli lunefull og ønsker å definere et felt som identifiserer hvert av menneskene som lever på planeten jorden, så bør vi be et BIGNIT -felt om hjelp, siden INT -typen bare tillater opptil to tusen millioner av forskjellige data, og det ville tydeligvis ikke nå oss.
Vi vil også bekrefte eksistensen av negative verdier, som vi kan finne når vi ønsker å lagre poengsummen til et spill, eller merket under null som blant annet kan markere et bord.
Usignerte verdier
La oss se på det slik: Å ha en negativ alder ville ikke være fornuftig i det hele tatt. Hvis det er mulighet for å doble grensen for maksimal positiv verdi for hver data og eliminere muligheten for at det feltet kan lagre negative verdier, ville vi doblet den positive lagringsgrensen, og feltet av typen TINYINT som normalt tillot å lagre verdier Av 127, nå kan du lagre verdier fra 0 til 255.
Og hvordan definerer vi et felt som ikke har tegn? Gjennom UNSIGNED -modifikatoren kan vi definere et numerisk felt. Ved å bruke dette bør vi finne en kolonne som leser Attributter og verdien av UNSIGNED, og dette feltet kan ikke lenger inneholde negative verdier, og dermed doble lagringskapasiteten.
Det er verdt å nevne at det er viktig at når vi definerer et felt i kolonnen som vi vil finne som Lengde, skriver vi et tall som er i samsvar med lagringskapasiteten vi nettopp har valgt. Fortsetter vi med eksempelet alder, hvis vi jobber med TINYNIT, må vi sette en treer som en lengde, ikke et større eller mindre tall.
Tall med desimaler
Priser, lønn, bankkontobeløp, blant annet, har vi flyttet til numeriske verdier med desimaler og vi har etterlatt hele tall, og til tross for at disse datatypene kalles "flytende punkt" fordi kommaet skiller delen heltall og desimaldel, faktisk mellom MySQL -datatyper, lagrer den dem som skiller dem med en periode; herfra ville vi ha tre typer data: FLOAT, DOUBLE og DECIMAL.
FLOAT lar oss lagre minst verdien -999.99 og høyst 999.99. Ta i betraktning at tegnet - ikke teller, men punktet som skiller dem, det vil si desimaltegnet, ja, derfor vil de være seks sifre totalt, selv om vi merker at to av dem er desimaler; Men vi har noe som kalles et enkelt presisjonsområde, som tvinger oss til å ha desimalmengder mellom 0 og 24.
På den annen side tillater DOUBLE, som er dobbelt så presis, bare antall desimaler mellom 25 og 23. Bruk FLOAT, som er enkel presisjon, kan forårsake avrundingsproblemer og tap av de resterende desimalene. Den som gjenstår å forklare er DECIMAL, som er den beste for lagring av pengeverdier der det kreves mindre lengde, men maksimal nøyaktighet, og uten avrunding tilordner denne typen data en fast bredde til tallet som skal lagres. Maksimumsifrene for denne typen data er 64, hvorav 30 er det maksimale antallet desimaler som er tillatt, mer enn nok til å lagre priser, lønninger og valutaer.
Alfanumeriske data
Til slutt forlater vi kategorien numeriske data for å legge inn en ny. Her skal vi snakke om lagring av tegnstrenger, for å forklare det på en bedre måte, og blant datatypene i MySQL har vi følgende: CHAR, VARCHAR, BINARY, VARBINARY, TINYBLOB, TINYTEXT, BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, ENUM og SET, hver og en har sine egne egenskaper og sine egne fordeler avhengig av hvilke data vi vil lagre.
Dato og tid data
Dette ville være vår siste kategori når det gjelder datatyper i MYSQL. Vi vil se at vi har flere alternativer for å lagre henviste data, datoer og klokkeslett, og se forskjellen mellom den ene og den andre og deres viktigste bruksområder. På denne måten vil vi kunne velge riktig type data i hvert tilfelle.
INFORMASJON
Denne typen data i MySQL lar oss lagre datoer der de fire første sifrene tilhører året, de to neste til måneden og de to siste til dagen, selv om vi i spansktalende land er vant til å bestille datoene først etter dagen, deretter for måneden, og deretter for året, for MYSQL er det helt omvendt.
Det er viktig å vite at når du leser et DATE -felt, selv om det vises med bindestreker som skiller året fra måneden og måneden fra dagen, kan vi se det som for eksempel når vi setter inn disse dataene for å gjøre alt kontinuerlig. dette: 2018-06-04 og sett det inn slik 20180604. Datoperioden som DATE lar oss håndtere er 1000-01-01 til 9999-12-31.
Med mindre vi har noe å gjøre med en hendelse som skjedde for to tusen år siden og vi må avsløre den, vil vi ikke ha noen problemer med dette formatet; på den annen side, med tanke på fremtiden har vi flere muligheter, siden vi med dette formatet nesten nådde året 10,000.
DATO TID
Å ha et felt definert som DATETIME vil tillate oss å lagre informasjon ikke for en dato, men for et øyeblikk, et øyeblikk, bortsett fra datoen, også tidsplanen, først ville vi ha året, deretter måneden, deretter dagen , da ville vi også ha timen, minuttene og til og med sekundene, formatet ser slik ut:
- ÅÅÅÅ- MM- DD HH: MM: SS
Datodelen har et område som ligner på DATE-typen (10,000 1000 år), det vil si fra 01-01-9999 til 12-31-00. Delen av timeplanen vil se slik ut: fra 00:00:23 til 53:53:1000. Alt komplett ville se slik ut: 01-01-00 00:00:9999 til 12-31-23 59:59:XNUMX.
TIME
Her har vi lov til å lagre timer, minutter og sekunder, og ja, den forrige datatypen gjorde det også, men med TIME har vi et tillatt område som går fra: -839: 59: 59 til 839: 59: 59; dette vil spenne omtrent 35 dager frem og tilbake på en aktuell dato. Denne typen data er ideell for å beregne forløpte tider mellom to nære øyeblikk.
TIMESTAMP
Her har vi en datatype som kan være veldig lik DATETIME, men formatet og området er forskjellige, selv om det fortsatt er nyttig for å lagre en dato og et klokkeslett. Med feltet for dette formatet kan tre alternativer presenteres for oss, det første er: ÅÅÅÅ-MM-DD HH: MM: SS, det andre er: ÅÅÅÅ-MM-DD, og det tredje er enklere: ÅÅ-MM-DD .
Her har vi muligheten til å ha en mulig lengde på 14, 8 eller 6 sifre, alt avhenger av informasjonen vi gir. Dette formatet er verken så historisk eller så futuristisk som de andre, siden området som dette feltet håndterer bare går fra 1970-01-01 til år 2037.
I tillegg kan vi som et merkelig faktum fastslå at verdien holdes automatisk oppdatert hver gang en post settes inn eller oppdateres, på denne måten vil vi alltid beholde datoen og klokkeslettet for vår siste oppdatering av disse dataene i dette feltet er virkelig ideell. å ta kontroll uten å måtte programmere noe.
Hvis vi vil definere dette fra phpMyAdmin, er det bare å velge alternativet som sier "ved oppdatering" CURRENT_TIMESTAMP, og som standardverdi CURRENT_TIMESTAMP. Felt hvis verdi kan oppdateres automatisk når du setter inn eller endrer en post.
ÅR
I tilfelle vi må se behovet for å definere et felt som YEAR, kan vi lagre et år, både ved å bruke to, så vel som fire sifre. I tilfelle vi gjør det med to sifre, fra 70 til 99 (med fra 70 til 99 vil vi forstå at disse tilsvarer årene fra 1970 til 1999, og hvis vi har sifrene fra 00 til 69 så kan vi forstå at det refererer til årene 2000 til 2069), i et slikt tilfelle med de fire sifrene vil vi finne ut at det mulige området vil bli utvidet og deretter gå fra 1901 til 2155.
Vi har også en ekstra mulighet, men ikke knyttet til datatyper i MySQL, men relatert til datoer og klokkeslett. Denne ekstra muligheten er å generere en tidsstempelverdi med PHP -tidsfunksjonen (igjen vil vi presisere at vi ikke lenger snakker om MYSQL, selv om det er gyldig å bli forvirret på grunn av å ha ganske like navn).
Uansett, vi kan lagre den verdien i et 10-sifret INT-felt, på denne måten vil det være veldig enkelt å bestille verdiene til feltet vårt (vi kan sette datoen for en nyhet som et eksempel) og så kan vi kan vise den datoen ved å omdanne verdien tidsstempel til noe som vi kan gjøre lesbart ved hjelp av PHPs egne datahåndteringsfunksjoner.
Jeg håper at vi med denne artikkelen om datatyper i MySQL har klart å gjøre alt vi ønsket å forklare tilstrekkelig klart, og at du har lært hvordan du oppretter en database og en tabell i henhold til all informasjonen vår, og definerer feltene med full presisjon. bruker dem typer data og attributter, derfor, i evnen eller i forholdene, til å begynne å programmere riktig, nå har en klar ide om nøyaktig hvilket format vi kommer til å trenge, som passer vårt behov i henhold til hva vi må programmere.
Vi inviterer deg til å nyte en av våre artikler relatert til programmering: Polymorfisme i objektorientert programmering.