Lærer du om databaseadministratorer? I så fald skal du informere dig selv om datatyper i MySQL, en af de bedste og mest brugte i verden. Gå ikke glip af muligheden!.
Datatyper i MySQL
Hver gang vi skal oprette en tabel, der kan bruges til at gemme data til et program, skal vi vide, hvordan vi kan identificere, hvilken type data der bruges til bedre at gemme alt det, vi har brug for til at arkivere. Vi kan vælge mellem tre: numeriske data, strenge (alfanumeriske) og datoer og tidspunkter.
I disse felter i MYSQL -tabellerne har vi mulighed for at vælge mellem tre typer indhold, og selvom det virker indlysende, bestemme hvor vi skal sende vores data, til hvilken type gruppe opbevaringen vil tilhøre, her har vi et eksempel til at sætte os selv i kontekst: ja vi har brug for et felt, som vi kan gemme en persons alder med, så ville det være et numerisk datafelt.
Men før jeg fortsætter med at forklare, ved du hvad MySQL er? Det er kendt som en af de mest udbredte open source databaseadministratorer i verden. Så vi kan få en idé om, hvor populær det er, vil vi fortælle dig, at: WordPress er leder af forskellige typer indhold, som har eksisteret siden 2003, og at omkring 55% til 60% af de websider, der findes, er lavet takket være dette, og det bruger MySQL som en database, så dette beviser, hvor nyttigt det kan være og omfanget, det har.
MySQL tilhører Oracle Corporation -virksomheden, der havde ansvaret for at købe den i 2010. Denne manager har flere anvendelser, såsom: praksis, udførelse af installationer, ændring af websider, læsning af data, blandt andre.
Denne driver kan let downloades og har flere versioner afhængigt af det Windows, du bruger, på samme måde er det meget let at installere det.
Langt de fleste databasedrivere bruges via et programmeringssprog. Lad os sige, at de oplysninger, vi har på vores computere, f.eks. Er tilgængelige i databasen, men når vi skal se og administrere dem, bruger de et programmeringssprog; I tilfælde af MySQL ledsages det af php, som er kendt som et webudviklingssprog, det samme som WordPress udvikles med.
Vi formoder, at vi for hastighed kan anbefale at downloade XAMPP -værktøjet, som er tilgængeligt til forskellige versioner af Windows. XAMPP leveres med en række komponenter, blandt dem har vi:
- Apache: Dette ville være en webserver.
- PHP: Webudviklingssproget.
- Fillezilla: Han har ansvaret for at mobilisere filerne.
- Kviksølv: Det er mailserveren, der har til formål at udføre testene.
- MySQL: Som vi nævnte tidligere, er det databaseserveren.
Efter installation af XAMPP vil du kunne nyde alle disse komponenter, herunder MySQL, som du kan starte direkte og oprette forbindelse til den grafiske grænseflade, derfor er XAMPP ekstremt nyttig udover at have de andre komponenter.
Da vi havde alt dette klart, ønskede vi at forklare, at inden for vores muligheder for typer af tabeller til lagring af vores data, og når vi taler om det numeriske datafelt, har vi inden for samme samme andre typer, og vi skal vide, hvilken der ville være den bedste, hvilket ville give os mulighed for at forbruge mindre fysisk lagerplads og vil give os mulighed for data, som vi håber at gemme på dette område. Den eneste måde at forstå disse spørgsmål på er de forskellige datatyper, MySQL giver os. Nedenfor giver vi disse oplysninger for at forstå den mest hensigtsmæssige anvendelse af hver gruppe.
Vi inviterer dig til at se et intensivt kursus om datatyper i MySQL og alt hvad du behøver at vide om det i videoen herunder. Gå ikke glip af muligheden for at lære!:
Numeriske data
Den forskel, vi kunne finde mellem en datatype og en anden i MySQL, er simpelthen den række værdier, den kan indeholde. Inden for de numeriske data skal vi se, at vi kan skelne mellem to store grene: heltal og decimaler; Nu vil vi gerne forklare de typer numeriske data, vi kan have i henhold til den situation, der præsenteres for os, og hvad vi har brug for:
Numeriske heltal
Det første, vi vil forklare på dette tidspunkt, er, at de muligheder, vi har for at gemme denne type data, ville være aldre, mængder og størrelser uden decimaler. Vi vil også gerne præsentere et eksempel for bedre at forstå, hvilken type data vi skal vælge for hvert felt:
Vi præsenterer TINYINT, en datatype, der giver os mulighed for at gemme en maksimalværdi på 127. Så hvis vi skal definere et felt for vores brugeres alder, er dette den, vi kunne bruge, fordi det normale aldersinterval er inden for dette tal , og medmindre vi lever i det bibelske Gamle Testamentes tid, oversteg ingen biologisk dette tal; Så nej, denne type data tillader os ikke at gemme 567, for eksempel ikke engang 128, hvis grænsen når 127.
Nu, hvis vi vil definere et felt til en identifikator for et stort marked til at sælge tusindvis af forskellige og varierede ting, ville dette ændre sig eksponentielt, klart TINYINT tjener os ikke længere, udover dette bør vi meget præcist kende mængden af varer det sælger, men ikke kun med det, vi har i øjeblikket, men forsøger at lave en forudsigelse for vores nærmeste fremtid, på denne måde bliver vores lagersystem ikke hurtigt forældet.
Vi kunne bruge noget som SMALLINT, der giver os mulighed for at tælle op til 32,000 artikler, men hvis vi ændrer eksemplet og flytter fra et marked til et ID -felt, der skulle bruges til et kundetabel i et telefonselskab med 5 millioner brugere, vi ikke længere kunne have af SMALLINT, men af nogle andre såsom MEDIUMINT, og vi fortsætter, i tilfælde af at vores virksomhed havde 200 millioner kunder, skulle vi bruge et felt af typen INT. Spørgsmålet ændrer sig i tilfælde af at blive lunefuld og ønsker at definere et felt, der identificerer hvert af de mennesker, der lever på planeten jorden, så bør vi bede et BIGNIT -felt om hjælp, da INT -typen kun tillader op til to tusind millioner af forskellige data, og det ville tydeligvis ikke nå os.
Vi vil også bekræfte eksistensen af negative værdier, som vi kunne finde, når vi ønsker at gemme partiets score, eller det mærke under nul, som et bord blandt andet kunne markere.
Usignerede værdier
Lad os se på det på denne måde: At have en negativ alder ville slet ikke give mening. Hvis der er mulighed for at fordoble grænsen for den maksimale positive værdi for hver data, hvilket eliminerer muligheden for, at dette felt kan gemme negative værdier, ville vi fordoble den positive lagringsgrænse og feltet af typen TINYINT, der normalt tillod at gemme værdier Af 127 lader dig nu gemme værdier fra 0 til 255.
Og hvordan definerer vi et felt, der ikke har noget tegn? Gennem UNSIGNED -modifikatoren kan vi definere et numerisk felt. Ved hjælp af dette skulle vi finde en kolonne, der læser attributter og værdien af UNSIGNED, og dette felt kan ikke længere indeholde negative værdier og dermed fordoble lagerkapaciteten.
Det er værd at nævne, at det er vigtigt, at når vi definerer et felt i kolonnen, som vi ville finde som længde, skriver vi et tal, der stemmer overens med den lagerkapacitet, vi lige har valgt. Hvis vi fortsætter med eksempel på alder, hvis vi arbejder med TINYNIT, skal vi sætte en treer som en længde, ikke et større eller mindre tal.
Tal med decimaler
Priser, lønninger, bankkontobeløb, blandt andet har vi flyttet til numeriske værdier med decimaler, og vi har efterladt heltal, og på trods af at disse datatyper kaldes "flydende punkt", fordi kommaet adskiller delheltallet og decimaldelen, faktisk mellem MySQL -datatyperne, gemmer den dem adskiller dem med en periode; herfra ville vi have tre typer data: FLOAT, DOUBLE og DECIMAL.
FLOAT giver os mulighed for at gemme mindst værdien -999.99 og højst 999.99. Tag i betragtning, at tegnet - ikke tæller, men det punkt, der adskiller dem, det vil sige decimalpunktet, ja, derfor ville de være seks cifre i alt, selvom vi bemærker, at to af dem er decimaler; Men vi har noget, der kaldes et simpelt præcisionsinterval, som tvinger os til at have decimalmængder mellem 0 og 24.
På den anden side tillader DOUBLE, der er dobbelt så præcis, kun at antallet af decimaler defineres mellem 25 og 23. Brug af FLOAT, som er enkel præcision, kan forårsage afrundingsproblemer og tab af de resterende decimaler. Den, der stadig skal forklares, er DECIMAL, som er den bedste til lagring af monetære værdier, hvor der kræves mindre længde, men maksimal nøjagtighed, og uden afrunding tildeler denne type data en fast bredde til det nummer, de vil gemme. Det maksimale samlede ciffer for denne type data er 64, hvoraf 30 er det maksimale antal decimaler, der er tilladt, mere end nok til at gemme priser, lønninger og valutaer.
Alfanumeriske data
Endelig forlader vi kategorien af numeriske data for at indtaste en ny. Her vil vi tale om at gemme tegnstrenge, for at forklare det på en bedre måde, og blandt datatyperne i MySQL har vi følgende: CHAR, VARCHAR, BINARY, VARBINARY, TINYBLOB, TINYTEXT, BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, ENUM og SET, hver har sine egne egenskaber og sine egne fordele afhængigt af hvilke data vi vil gemme.
Dato og tid data
Dette ville være vores sidste kategori, når det kommer til datatyper i MYSQL. Vi vil se, at vi har flere muligheder for at gemme henviste data, datoer og tidspunkter, idet vi ser forskellen mellem den ene og den anden og deres vigtigste anvendelser, på denne måde vil vi i hvert tilfælde kunne vælge den passende datatype.
INFORMATION
Denne type data i MySQL giver os mulighed for at gemme datoer, hvor de første fire cifre hører til året, de næste to til måneden og de sidste to til dagen, selvom vi i spansktalende lande er vant til at bestille datoerne først ved dagen, derefter for måneden og derefter for året, for MYSQL er det helt omvendt.
Det er vigtigt at vide, at når vi læser et DATE -felt, selvom det vises med bindestreger, der adskiller år fra måned og måned fra dag, kan vi se det som f.eks. Ved at indsætte disse data for at gøre alt kontinuerligt. dette: 2018-06-04 og indsæt det sådan 20180604. Datointervallet, DATE giver os mulighed for at håndtere, er 1000-01-01 til og med 9999-12-31.
Medmindre vi har noget at gøre med en begivenhed, der skete for to tusinde år siden, og vi er nødt til at afsløre den, har vi ingen problemer med dette format; på den anden side med henblik på fremtiden har vi flere muligheder, da vi med dette format næsten nåede år 10,000.
DATO TID
Når vi har et felt defineret som DATETIME, vil vi ikke kunne gemme oplysninger om en dato, men om et øjeblik, et øjeblik, bortset fra datoen, også dens tidsplan, først ville vi have året, derefter måneden, derefter dagen , så ville vi også have timen, minutterne og endda sekunder, formatet ser sådan ud:
- ÅÅÅÅ- MM- DD HH: MM: SS
Datodelen har et område, der ligner det for DATE-typen (10,000 år), det vil sige fra 1000-01-01 til 9999-12-31. Delen af skemaet ville se sådan ud: fra 00:00:00 til 23:53:53. Alt komplet ville se sådan ud: 1000-01-01 00:00:00 til 9999-12-31 23:59:59.
TIME
Her har vi lov til at gemme timer, minutter og sekunder, og ja, det gjorde den tidligere datatype også, men med TIME har vi et tilladt område, der går fra: -839: 59: 59 til 839: 59: 59; dette ville strække sig omkring 35 dage frem og tilbage på en aktuel dato. Denne type data er ideel til beregning af forløbne tider mellem to tætte øjeblikke.
TIDSSTEMPEL
Her har vi en datatype, der kan være meget lig DATETIME, men dens format og rækkevidde er forskellige, selvom det stadig er nyttigt til at gemme en dato og et tidspunkt. Med feltet for dette format kan tre muligheder præsenteres for os, den første er: ÅÅÅÅ-MM-DD HH: MM: SS, den anden er: ÅÅÅÅ-MM-DD, og den tredje er enklere: ÅÅ-MM- DD.
Her har vi mulighed for at have en mulig længde på 14, 8 eller 6 cifre, det hele afhænger af de oplysninger, vi giver. Dette format er hverken så historisk eller så futuristisk som de andre, da det område, dette felt håndterer, kun går fra 1970-01-01 til år 2037.
Desuden kan vi som en besynderlig kendsgerning fastslå, at dens værdi automatisk opdateres hver gang en post indsættes eller opdateres, på denne måde vil vi altid i dette felt beholde datoen og klokkeslættet for vores sidste opdatering af disse data, som er virkelig ideel. at tage kontrol uden at skulle programmere noget.
Hvis vi vil definere dette fra phpMyAdmin, er alt, hvad vi skal gøre, i Attributter at vælge indstillingen, der siger "ved opdatering" CURRENT_TIMESTAMP, og som standardværdien CURRENT_TIMESTAMP. Felt, hvis værdi kan opdateres automatisk, når der indsættes eller ændres en post.
ÅR
I tilfælde af at vi skal se behovet for at definere et felt som YEAR, kan vi gemme et år, både ved hjælp af to såvel som fire cifre. I tilfælde af at vi gør det med to cifre, fra 70 til 99 (med fra 70 til 99 forstår vi, at disse svarer til årene fra 1970 til 1999, og hvis vi har cifrene fra 00 til 69, kan vi forstå, der refererer til årene 2000 til 2069), i sådanne tilfælde med angivelse af de fire cifre ville vi opdage, at det mulige område ville blive udvidet og derefter gå fra 1901 til 2155.
Vi har også en ekstra mulighed, selvom den ikke er relateret til datatyper i MySQL, men relateret til datoer og tidspunkter. Denne ekstra mulighed er at generere en tidsstempelværdi med PHP -tidsfunktionen (igen vil vi præcisere, at vi ikke længere taler om MYSQL, selvom det er gyldigt at blive forvirret på grund af at have ganske lignende navne).
Anyway, vi kunne gemme denne værdi i et 10-cifret INT-felt, på denne måde vil det være meget enkelt at bestille værdierne i vores felt (vi kan sætte datoen for en nyhed som et eksempel), og så vi kan vise denne dato ved at omdanne værditidsstemplet til noget, som vi kan gøre læsbart ved hjælp af PHPs egne datahåndteringsfunktioner.
Jeg håber, at vi med denne artikel om datatyper i MySQL har været i stand til at gøre alt, hvad vi ønskede at forklare tilstrækkeligt klart, og at du har lært, hvordan du opretter en database og en tabel i henhold til alle vores oplysninger, med fuld præcision at definere deres felter ved at bruge dem typer data og attributter, derfor i evnen eller i forholdene, til at begynde at programmere korrekt, nu have en klar idé om præcis hvilket format vi skal bruge, hvilket passer til vores behov i henhold til hvad vi skal programmere.
Vi inviterer dig til at nyde en af vores artikler om programmering: Polymorfisme i objektorienteret programmering.