Datatyper i MYSQL att använda i databaser

Lär du dig om databashanterare? I så fall måste du informera dig själv om datatyper i MySQL, en av de bästa och mest använda i världen. Missa inte chansen!.

Datatyper-i-Mysql-2

Datatyper i MySQL

Varje gång vi behöver skapa en tabell som kan användas för att lagra data för ett program, måste vi veta hur vi identifierar vilken typ av data som hjälper oss att bättre lagra allt vi behöver för att arkivera. Vi kan välja mellan tre: numeriska data, strängar (alfanumeriska) och datum och tider.

I dessa fält i MYSQL -tabellerna har vi möjlighet att välja mellan tre typer av innehåll, och även om det verkar självklart, bestämma vart vi ska skicka våra data, till vilken typ av grupp lagringen kommer att tillhöra, här har vi ett exempel att sätta oss själva i sammanhang: ja vi behöver ett fält som vi kan lagra en persons ålder med, då skulle det vara ett numeriskt datafält.

Men innan jag fortsätter att förklara, vet du vad MySQL är? Det är känt som en av de mest använda open source -databashanterna i världen. Så att vi kan få en uppfattning om hur populärt det är, kommer vi att berätta att: WordPress är chef för olika typer av innehåll, som har funnits sedan 2003, och att cirka 55% till 60% av de webbsidor som finns, görs tack vare detta, och det använder MySQL som en databas, så detta bevisar hur användbart det kan vara och omfattningen det har.

MySQL tillhör Oracle Corporation -företaget, som ansvarade för att köpa det 2010. Den här chefen har flera användningsområden, till exempel: praxis, utför installationer, modifierar webbsidor, läser data, bland andra.

Denna drivrutin kan enkelt laddas ner och har flera versioner beroende på vilket Windows du använder, på samma sätt är det väldigt enkelt att installera den.

De allra flesta databasdrivrutiner används via ett programmeringsspråk. Låt oss säga att till exempel den information som vi har på våra datorer är tillgänglig i databasen, men när vi behöver se och hantera den använder den ett programmeringsspråk; När det gäller MySQL åtföljs det av php, som är känt som ett webbutvecklingsspråk, samma som WordPress utvecklas med.

Vi antar att vi för hastighet kan rekommendera att ladda ner XAMPP -verktyget, som är tillgängligt för olika versioner av Windows. XAMPP kommer med en serie komponenter, bland dem har vi:

  • Apache: Detta skulle vara en webbserver.
  • PHP: Språket för webbutveckling.
  • Fillezilla: Han ansvarar för att mobilisera filerna.
  • Kvicksilver: Det är e -postservern som har till syfte att göra testerna.
  • MySQL: Som vi nämnde tidigare är det databaseservern.

Efter installationen av XAMPP kommer du att kunna njuta av alla dessa komponenter, inklusive MySQL, som du kan starta direkt och ansluta till det grafiska gränssnittet, det är därför XAMPP är extremt användbart, förutom att ha de andra komponenterna.

Med allt detta klart ville vi förklara att vi inom våra alternativ för tabelltyper för att lagra våra data, och talar om det numeriska datafältet, inom samma har andra typer, och vi måste veta vilken som skulle vara bäst, vilket skulle ge oss möjlighet att konsumera mindre fysiskt lagringsutrymme och kommer att ge oss möjlighet till data som vi hoppas kunna lagra på det området. Det enda sättet att förstå dessa frågor är de olika typerna av data som MySQL tillhandahåller oss, nedan kommer vi att tillhandahålla den informationen för att förstå den lämpligaste användningen av varje grupp.

Vi inbjuder dig att se en intensiv kurs om datatyper i MySQL och allt du behöver veta om det i videon nedan. Missa inte chansen att lära dig!:

Numerisk data

Skillnaden som vi kan hitta mellan en typ av data och en annan i MySQL är helt enkelt det värdeområde som den kan innehålla. Inom de numeriska uppgifterna måste vi se vad vi kan skilja mellan två stora grenar: heltal och decimaler; Nu skulle vi vilja förklara vilka typer av numeriska data vi kan ha utifrån den situation som presenteras för oss och vad vi behöver:

Numeriska heltal

Det första vi vill förklara vid denna tidpunkt är att alternativen vi har för att lagra denna typ av data skulle vara åldrar, kvantiteter och storheter utan decimaler. Vi skulle också vilja presentera ett exempel för att bättre förstå vilken typ av data vi ska välja för varje fält:

Vi presenterar TINYINT, en datatyp som gör att vi kan lagra ett maximivärde på 127. Så om vi behöver definiera ett fält för våra användares ålder är det här vi kan använda, eftersom det normala åldersintervallet ligger inom det numret , och om vi inte lever under den bibliska Gamla testamentets tid, överträffade ingen biologiskt det antalet; Så nej, den här typen av data tillåter oss inte att lagra 567, till exempel inte ens 128, om gränsen når 127.

Nu, om vi vill definiera ett fält för en identifierare för en stor marknad för att sälja tusentals olika och varierade saker, skulle detta förändras exponentiellt, uppenbarligen tjänar TINYINT oss inte längre, förutom detta bör vi veta mycket exakt mängden objekt det säljer, men inte bara med det vi för närvarande har, utan försöker göra en förutsägelse för vår nära framtid, på så sätt kommer vårt lagringssystem inte snabbt att bli föråldrat.

Vi kan använda något som SMALLINT som gör att vi kan räkna upp till 32,000 5 artiklar, men om vi ändrar exemplet och går från en marknad till ett ID -fält som ska användas för ett kundbord för ett telefonbolag med 200 miljoner användare, vi kunde inte längre ha av SMALLINT, men av några andra som MEDIUMINT, och vi fortsätter, om vårt företag hade XNUMX miljoner kunder, bör vi använda ett fält av typen INT. Frågan förändras när vi blir nyckfulla och vill definiera ett fält som identifierar var och en av de människor som lever på planeten jorden, då bör vi be ett BIGNIT -fält om hjälp, eftersom INT -typen bara tillåter upp till två tusen miljoner olika uppgifter, och det skulle helt klart inte nå oss.

Vi vill också bekräfta förekomsten av negativa värden, som vi kan hitta när vi vill spara poängen i ett spel, eller markeringen under noll som en tabell kan markera, bland annat.

Osignerade värden

Låt oss titta på det så här: att ha en negativ ålder skulle inte vara meningsfullt alls. Om det finns möjlighet att fördubbla gränsen för det maximala positiva värdet för varje data, vilket eliminerar möjligheten att det fältet kan lagra negativa värden, skulle vi fördubbla den positiva gränsen för lagring och fältet av typen TINYINT som normalt tillåter att lagra värden Av 127, nu kan du lagra värden från 0 till 255.

Och hur definierar vi ett fält som inte har något tecken? Genom UNSIGNED -modifieraren kan vi definiera ett numeriskt fält. Med hjälp av detta bör vi hitta en kolumn som läser attribut och värdet för UNSIGNED och det här fältet kan inte längre innehålla negativa värden, vilket fördubblar lagringskapaciteten.

Det är värt att nämna att det är viktigt att när vi definierar ett fält i kolumnen som vi skulle hitta som längd skriver vi ett nummer som överensstämmer med lagringskapaciteten som vi just valt. Om vi ​​fortsätter med exempel på ålder, om vi arbetar med TINYNIT, måste vi sätta en trea som en längd, inte ett större eller mindre tal.

Siffror med decimaler

Priser, löner, bankkontobelopp, bland annat, vi har flyttat till numeriska värden med decimaler och vi har lämnat efter oss heltal, och trots att dessa datatyper kallas "flytande punkt" eftersom kommatecknet skiljer delen heltal och decimaldelen, faktiskt mellan MySQL -datatyperna, den lagrar dem och separerar dem med en punkt; härifrån skulle vi ha tre typer av data: FLOAT, DOUBLE och DECIMAL.

FLOAT gör att vi kan lagra minst värdet -999.99 och högst 999.99. Låt oss ta hänsyn till att tecknet - inte räknas, men den punkt som skiljer dem, det vill säga decimalpunkten, ja, det är därför de skulle vara totalt sex siffror, även om vi noterar att två av dem är decimaler; Men vi har något som kallas ett enkelt precisionsintervall, vilket tvingar oss att ha decimalmängder mellan 0 och 24.

Å andra sidan tillåter DOUBLE, som är dubbelt så mycket precision, endast antalet decimaler mellan 25 och 23. Att använda FLOAT, som är enkel precision, kan orsaka avrundningsproblem och förlust av de återstående decimalerna. Den som återstår att förklara är DECIMAL, vilket är det bästa för att lagra monetära värden där mindre längd krävs men maximal noggrannhet, och utan avrundning tilldelar denna typ av data en fast bredd till det nummer som ska lagras. Den maximala totala siffran för denna typ av data är 64, varav 30 är det maximala antalet decimaler som är tillåtna, mer än tillräckligt för att lagra priser, löner och valutor.

decimal-1

Alfanumeriska data

Slutligen lämnar vi kategorin numerisk data för att ange en ny. Här kommer vi att prata om att lagra teckensträngar, för att förklara det på ett bättre sätt, och bland datatyperna i MySQL har vi följande: CHAR, VARCHAR, BINARY, VARBINARY, TINYBLOB, TINYTEXT, BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, ENUM och SET, var och en har sina egna egenskaper och sina egna fördelar beroende på vilken data vi vill lagra.

Datum och tid

Detta skulle vara vår sista kategori när det gäller datatyper i MYSQL. Vi kommer att se att vi har flera alternativ för att lagra hänvisad data, datum och tider, se skillnaden mellan den ena och den andra och deras huvudsakliga användningsområden. På så sätt kommer vi att kunna välja lämplig typ av data i varje fall.

DATUM

Denna typ av data i MySQL tillåter oss att lagra datum där de första fyra siffrorna skulle tillhöra året, de två nästa till månaden och de två sista till dagen, även om vi i spansktalande länder är vana vid att beställa datum först för dagen, sedan för månaden och sedan för året, för MYSQL är det helt tvärtom.

Det är viktigt att veta att när vi läser ett DATE -fält, även om det visas med streck som skiljer året från månaden och månaden från dagen, kan vi se det som när vi lägger in dessa data till exempel allt kontinuerligt. detta: 2018-06-04 och sätt in det så här 20180604. Datumintervallet som DATE tillåter oss att hantera är 1000-01-01 till 9999-12-31.

Om vi ​​inte har något att göra med en händelse som hände för två tusen år sedan och vi behöver avslöja den, kommer vi inte att ha några problem med detta format; å andra sidan, med tanke på framtiden har vi fler möjligheter, eftersom vi med detta format nästan nådde året 10,000 XNUMX.

Datum Tid

Med ett fält definierat som DATETIME kan vi lagra information inte för ett datum, utan för ett ögonblick, en ögonblick, förutom datumet, även dess schema, först skulle vi ha året, sedan månaden, sedan dagen , då skulle vi också ha timme, minuter och till och med sekunder, formatet ser ut så här:

  • ÅÅÅÅ- MM- DD HH: MM: SS

Datumdelen har ett intervall som liknar det av DATE-typen (10,000 1000 år), det vill säga från 01-01-9999 till 12-31-00. Delen av schemat skulle se ut så här: från 00:00:23 till 53:53:1000. Allt komplett ser ut så här: 01-01-00 00:00:9999 till 12-31-23 59:59:XNUMX.

TID

Här får vi lagra timmar, minuter och sekunder, och ja, den tidigare datatypen gjorde det också, men med TIME har vi ett tillåtet intervall som går från: -839: 59: 59 till 839: 59: 59; detta skulle sträcka sig cirka 35 dagar fram och tillbaka på ett aktuellt datum. Denna typ av data är idealisk för att beräkna förflutna tider mellan två stängningsmoment.

TIDSSTÄMPEL

Här har vi en datatyp som kan vara mycket lik DATETIME men dess format och intervall är olika, även om det fortfarande är användbart för att lagra ett datum och en tid. Med fältet för detta format kan tre alternativ presenteras för oss, det första är: ÅÅÅÅ-MM-DD HH: MM: SS, det andra är: ÅÅÅÅ-MM-DD och det tredje är enklare: ÅÅ-MM-DD .

Här har vi möjlighet att ha en möjlig längd på 14, 8 eller 6 siffror, allt beror på vilken information vi tillhandahåller. Detta format är varken lika historiskt eller futuristiskt som de andra, eftersom intervallet som detta område hanterar bara går från 1970-01-01 till år 2037.

Dessutom kan vi som ett märkligt faktum fastställa att dess värde hålls automatiskt uppdaterat varje gång en post sätts in eller uppdateras, på detta sätt kommer vi alltid att hålla i detta fält datum och tid för vår senaste uppdatering av data, som är verkligen perfekt. att ta kontroll utan att behöva programmera något.

Om vi ​​vill definiera detta från phpMyAdmin är allt vi behöver göra att välja i attribut alternativet som säger "vid uppdatering" CURRENT_TIMESTAMP och som standardvärdet CURRENT_TIMESTAMP. Fält vars värde kan uppdateras automatiskt när en post läggs till eller ändras.

ÅR

Om vi ​​måste se behovet av att definiera ett fält som YEAR kan vi lagra ett år, både med två och fyra siffror. Om vi ​​gör det med två siffror, från 70 till 99 (med 70 till 99 kommer vi att förstå att dessa motsvarar åren mellan 1970 och 1999, och om vi har siffrorna från 00 till 69 kan vi förstå som avser åren 2000 till 2069), i ett sådant fall att ge de fyra siffrorna då skulle vi upptäcka att det möjliga intervallet skulle expandera och sedan gå från 1901 till 2155.

Vi har också en extra möjlighet, även om de inte är relaterade till datatyper i MySQL, men relaterade till datum och tider. Denna extra möjlighet är att generera ett tidsstämpelvärde med PHP -tidsfunktionen (igen vill vi förtydliga att vi inte längre pratar om MYSQL, även om det är giltigt att bli förvirrad på grund av att de har ganska lika namn).

Hur som helst kan vi lagra det värdet i ett tio-siffrigt INT-fält, på så sätt blir det väldigt enkelt att beställa värdena för vårt fält (vi kan sätta datumet för en nyhet som ett exempel) och sedan vi kan visa det datumet genom att omvandla värdetidsstämpeln till något som vi kan göra läsbart med PHP: s egna datumhanteringsfunktioner.

datum-tid-1

Jag hoppas att vi med denna artikel om datatyper i MySQL har kunnat göra allt vi ville förklara tillräckligt tydligt och att du har lärt dig att skapa en databas och en tabell enligt all vår information, definiera deras fält med total precision med dem som datatyper och attribut, därför att de är i förmågan eller under förutsättningarna att börja programmera ordentligt och nu har en klar uppfattning om exakt vilket format vi kommer att behöva, vilket passar vårt behov enligt vad vi har att programmera.

Vi inbjuder dig att njuta av en annan av våra artiklar relaterade till programmering: Polymorfism i objektorienterad programmering.


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Actualidad Blog
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.