Tanulsz az adatbázis -kezelőkről? Ebben az esetben tájékoztatnia kell magát a adattípusok a MySQL -ben, az egyik legjobb és leggyakrabban használt a világon. Ne hagyja ki a lehetőséget!
Adattípusok a MySQL -ben
Minden alkalommal, amikor létre kell hoznunk egy táblázatot, amely egy alkalmazás adatainak tárolására szolgál, tudnunk kell, hogyan kell azonosítani, hogy milyen típusú adatokat használunk az archiváláshoz szükséges minden jobb tároláshoz. Három közül választhatunk: numerikus adatok, karakterláncok (alfanumerikus), valamint dátumok és időpontok.
A MYSQL táblák ezen mezőiben lehetőségünk van háromféle tartalom közül választani, és bár nyilvánvalónak tűnik, határozzuk meg, hová küldjük adatainkat, milyen típusú csoporthoz fog tartozni a tároló, itt van egy példa, amellyel magunknak tehetjük meg összefüggésben: igen, szükségünk van egy mezőre, amellyel tárolhatjuk az ember életkorát, akkor ez egy numerikus adatmező lenne.
De mielőtt folytatnám a magyarázatot, tudja, mi a MySQL? A világ egyik legszélesebb körben használt nyílt forráskódú adatbázis -kezelőjeként ismert. Annak érdekében, hogy elképzelhessük, mennyire népszerű, elmondjuk Önnek, hogy: A WordPress a 2003 óta létező különböző típusú tartalmak kezelője, és a weboldalak körülbelül 55-60% -a léteznek, ennek köszönhetően készülnek, és a MySQL -t használja adatbázisként, így ez bizonyítja, hogy mennyire hasznos és milyen hatókörrel rendelkezik.
A MySQL az Oracle Corporation vállalaté, amely 2010 -ben volt felelős a megvásárlásáért. Ennek a menedzsernek többféle felhasználási területe van, például: gyakorlatok, telepítések végrehajtása, weboldalak módosítása, adatok olvasása.
Ez az illesztőprogram könnyen letölthető, és több verziója is van a használt Windows rendszertől függően, ugyanúgy, nagyon könnyű telepíteni.
Az adatbázis -illesztőprogramok túlnyomó részét programozási nyelven használják. Tegyük fel, hogy például a számítógépünkön tárolt információ elérhető az adatbázisban, de amikor meg kell néznünk és kezelnünk kell, akkor egy programozási nyelvet használ; A MySQL esetében a php kíséri, amely webfejlesztési nyelvként ismert, ugyanaz, amellyel a WordPress -t fejlesztik.
Feltételezzük, hogy gyorsaság érdekében javasoljuk az XAMPP eszköz letöltését, amely a Windows különböző verzióihoz érhető el. Az XAMPP számos összetevőt tartalmaz, köztük a következők:
- Apache: Ez egy webszerver lenne.
- PHP: A webfejlesztési nyelv.
- Fillezilla: Ő a felelős az akták mozgósításáért.
- Merkúr: Ez a levelezőszerver, amelynek célja a tesztek elvégzése.
- MySQL: Mint korábban említettük, ez az adatbázis szerver.
Az XAMPP telepítése után élvezheti mindezeket az összetevőket, beleértve a MySQL -t is, amelyet közvetlenül elindíthat, és csatlakozhat a grafikus felülethez, ezért az XAMPP rendkívül hasznos a többi összetevő mellett.
Mindezek tisztázásával szeretnénk elmagyarázni, hogy az adatok tárolására szolgáló táblázattípusokra vonatkozó lehetőségeink között, és ha a numerikus adatmezőről beszélünk, ezen belül más típusok is vannak, és tudnunk kell, melyik lenne a legjobb, melyik lehetőséget ad számunkra, hogy kevesebb fizikai tárhelyet fogyasszunk, és lehetőséget biztosít számunkra az adatok tárolására, amelyeket reméljük ezen a területen tárolunk. Az egyetlen módja annak, hogy megértsük ezeket a kérdéseket, a különböző típusú adatok, amelyeket a MySQL biztosít számunkra, az alábbiakban ezeket az információkat adjuk meg, hogy megértsük az egyes csoportok legmegfelelőbb felhasználását.
Meghívjuk Önt, hogy nézzen meg egy intenzív tanfolyamot a MySQL adattípusairól és mindenről, amit erről tudnia kell, az alábbi videóban. Ne hagyja ki a tanulási lehetőséget!:
Numerikus adatok
A különbség, amelyet a MySQL egyik és másik típusú adatai között találhatunk, egyszerűen az általuk tartalmazható értéktartomány. A numerikus adatokon belül látnunk kell, hogy két nagy ágat tudunk megkülönböztetni: egész és tizedes; Most szeretnénk elmagyarázni, hogy milyen típusú számadatok állnak rendelkezésünkre a számunkra bemutatott helyzetnek megfelelően, és mire van szükségünk:
Numerikus egész számok
Az első dolog, amit ezen a ponton szeretnénk elmagyarázni, az, hogy az ilyen típusú adatok tárolásának lehetőségei az életkorok, mennyiségek és nagyságrendek tizedesjegyek nélkül. Egy példát is szeretnénk bemutatni, hogy jobban megértsük, milyen típusú adatokat válasszunk az egyes mezőkhöz:
Bemutatjuk a TINYINT adattípust, amely lehetővé teszi számunkra, hogy legfeljebb 127 értéket tároljunk. Tehát ha meg kell határoznunk egy mezőt felhasználóink életkorához, akkor ezt használhatjuk, mert a normál korosztály ezen a számon belül van , és hacsak nem a bibliai Ószövetség idejét éljük, biológiailag senki sem lépte túl ezt a számot; Tehát nem, az ilyen típusú adatok nem teszik lehetővé, hogy például 567 -et tároljunk, például még 128 -at sem, ha a határ eléri a 127 -et.
Ha most egy mezőt szeretnénk definiálni egy nagy piac azonosítójához, hogy több ezer különböző és változatos dolgot értékesítsünk, ez exponenciálisan megváltozna, nyilvánvalóan a TINYINT már nem szolgál minket, emellett nagyon pontosan tudnunk kell a tételek mennyiségét eladja, de nem csak azzal, amellyel jelenleg rendelkezünk, hanem a közeljövőre vonatkozó előrejelzéssel próbálkozik, ily módon a tárolórendszerünk nem fog gyorsan elavulni.
Használhatnánk olyasmit, mint a SMALLINT, amely lehetővé teszi számunkra, hogy akár 32,000 5 cikket is számozzunk, de ha megváltoztatjuk a példát, és a piacról az azonosító mezőre térünk át, amelyet egy 200 millió felhasználóval rendelkező telefontársaság ügyfélasztalához kell használni, akkor nem rendelkezhet többé a SMALLINT -vel, hanem másokkal, mint például a MEDIUMINT, és abban az esetben, ha cégünknek XNUMX millió ügyfele van, INT típusú mezőt kell használnunk. A kérdés megváltozik abban az esetben, ha szeszélyes lesz, és olyan mezőt akar meghatározni, amely azonosítja a Földön élő összes embert, akkor kérjünk segítséget egy BIGNIT mezőtől, mivel az INT típus csak kétezer millió különböző adatokat, és ez nyilvánvalóan nem érne el minket.
Azt is meg akarjuk erősíteni, hogy léteznek negatív értékek, amelyeket akkor találhatunk, ha el akarjuk menteni egy játék pontszámát, vagy azt a nulla alatti jelet, amelyet egy asztal többek között megjelölhet.
Aláíratlan értékek
Nézzük így: negatív korúnak egyáltalán nem lenne értelme. Ha lehetőség van arra, hogy megduplázzuk az egyes adatok maximális pozitív értékének korlátját, kizárva annak lehetőségét, hogy az adott mező negatív értékeket tároljon, akkor megduplázzuk a tárolás pozitív korlátját, és a TINYINT típusú mezőt, amely általában lehetővé tette az értékek tárolását A 127 -ből mostantól 0 és 255 közötti értékeket tárolhat.
És hogyan határozzuk meg azt a mezőt, amelynek nincs jele? Az UNSIGNED módosítón keresztül numerikus mezőt definiálhatunk. Ennek segítségével egy oszlopot kell találnunk, amely az Attribútumok és az UNSIGNED értékét olvassa, és ez a mező már nem tartalmazhat negatív értékeket, ezáltal megduplázva tárolási kapacitását.
Érdemes megemlíteni, hogy fontos, hogy amikor meghatározunk egy mezőt az oszlopban, amelyet hosszként találunk, írjunk be egy számot, amely megfelel az éppen kiválasztott tárolókapacitásnak. Folytatva a kor példájával, ha a TINYNIT -el dolgozunk, akkor hármat kell megadnunk, nem pedig nagyobb vagy kisebb számot.
Számok tizedesjegyekkel
Többek között árak, fizetések, bankszámlaösszegek tizedes számjegyekkel tértünk át, és egész számokat hagytunk magunk mögött, és annak ellenére, hogy ezeket az adattípusokat "lebegőpontos" -nak nevezzük, mert a vessző elválasztja az egész részt és a tizedes rész, valójában a MySQL adattípusok között, tárolja őket, elkülönítve őket egy ponttal; innen háromféle adatunk lenne: FLOAT, DOUBLE és DECIMAL.
A FLOAT lehetővé teszi, hogy legalább -999.99 és legfeljebb 999.99 értéket tároljunk. Vegyük figyelembe, hogy a jel - nem számít, hanem az a pont, amely elválasztja őket, vagyis a tizedespont, igen, ezért lennének összesen hat számjegyűek, bár megjegyzzük, hogy kettő tizedesjegy; de van valami, amit egyszerű precíziós tartománynak hívunk, ami arra kényszerít bennünket, hogy tizedes mennyiségek legyenek 0 és 24 között.
Másrészről a DOUBLE kétszeres pontossággal csak a tizedesjegyek számának meghatározását teszi lehetővé 25 és 23 között. A FLOAT használata, amely egyszerű pontosság, kerekítési problémákat és a többi tizedesjegy elvesztését okozhatja. A magyarázandó még a DECIMAL, amely a legjobb a monetáris értékek tárolására, ahol kevesebb hosszúságra van szükség, de maximális pontosság, és kerekítés nélkül az ilyen típusú adatok rögzített szélességet rendelnek a tárolni kívánt számhoz. Az ilyen típusú adatok maximális számjegye 64, ebből 30 a megengedett tizedesjegyek maximális száma, több mint elegendő az árak, bérek és valuták tárolásához.
Alfanumerikus adatok
Végül elhagyjuk a numerikus adatok kategóriáját, hogy újat adjunk meg. Itt a karakterláncok tárolásáról, jobb magyarázatáról lesz szó, és a MySQL adattípusai között a következők találhatók: CHAR, VARCHAR, BINARY, VARBINARY, TINYBLOB, TINYTEXT, BLOB, TEXT, MEDIUMBLOB, MEDIUMTEXT, LONGBLOB, LONGTEXT, ENUM és SET, mindegyiknek megvannak a sajátosságai és előnyei attól függően, hogy milyen adatokat szeretnénk tárolni.
Dátum és idő adatok
Ez lenne az utolsó kategóriánk, amikor a MYSQL adattípusairól van szó. Látni fogjuk, hogy számos lehetőségünk van a hivatkozott adatok, dátumok és időpontok tárolására, látva a különbséget az egyik és a másik között, valamint azok fő felhasználási módjait, így minden esetben kiválaszthatjuk a megfelelő típusú adatokat.
DÁTUM
Az ilyen típusú adatok a MySQL-ben lehetővé teszik, hogy olyan dátumokat tároljunk, ahol az első négy számjegy az évhez tartozik, a következő kettő a hónaphoz, az utolsó kettő pedig a naphoz, bár a spanyol nyelvű országokban megszoktuk, hogy a dátumokat először a nap, majd a hónap, majd az év, a MYSQL esetében teljesen fordítva.
Fontos tudnunk, hogy a DÁTUM mező olvasásakor, bár kötőjelekkel jelenik meg, amelyek elválasztják az évet a hónaptól és a hónapot a naptól, ezen adatok beillesztésekor lehetővé teszi, hogy mindent folyamatosan folytassunk, például láthatjuk, hogy ezt: 2018-06-04 és illessze be így: 20180604. A dátumtartomány, amelyet a DATE lehetővé tesz számunkra, 1000-01-01 és 9999-12-31 között van.
Hacsak nincs valami közünk egy kétezer évvel ezelőtti eseményhez, és le kell tennünk, akkor nem lesz gondunk ezzel a formátummal; másrészt a jövőre való tekintettel több lehetőségünk van, hiszen ezzel a formátummal majdnem elértük a 10,000 -et.
DÁTUM IDŐ
Ha a DATETIME mezőt definiálja, akkor nem egy dátumról, hanem egy pillanatról, egy pillanatról, a dátumtól és annak ütemezésétől függően tárolhatunk információkat, először az év, majd a hónap, majd a nap áll rendelkezésünkre , akkor az óra, a perc és még a másodperc is megvan, a formátum így néz ki:
- ÉÉÉÉ- HH-NN ÓÓ: MM: SS
A dátumrész tartománya hasonló a DATE típuséhoz (10,000 1000 év), azaz 01-01-9999 és 12-31-00 között. A menetrend része így menne: 00:00:23 és 53:53:1000 között. Minden komplett így nézne ki: 01-01-00 00:00:9999-12-31-23 59:59:XNUMX.
IDŐ
Itt megengedjük, hogy órákat, perceket és másodperceket tároljunk, és igen, az előző adattípus is ezt tette, de a TIME paraméterrel megengedett tartományunk van: -839: 59: 59 -839: 59: 59; ez körülbelül 35 napig tartana oda -vissza egy aktuális dátumon. Az ilyen típusú adatok ideálisak két közeli pillanat közötti eltelt idő kiszámításához.
IDŐBÉLYEG
Itt van egy adattípusunk, amely nagyon hasonló lehet a DATETIME -hoz, de formátuma és tartománya eltérő, bár továbbra is hasznos a dátum és az idő tárolása. Ennek a formátumnak a mezőjével három lehetőség áll rendelkezésünkre, az első: YYYY-MM-DD HH: MM: SS, a második: YYYY-MM-DD, a harmadik pedig egyszerűbb: YY-MM- DD.
Itt lehetőségünk van 14, 8 vagy 6 számjegy hosszúságra, mindez az általunk megadott információktól függ. Ez a formátum nem olyan történelmi és nem olyan futurisztikus, mint a többi, mivel ez a mező csak 1970-01-01-től 2037-ig terjed.
Ezenkívül különös tényként megállapíthatjuk, hogy értéke minden rekord beillesztésekor vagy frissítésekor automatikusan frissül, így ezen a területen mindig megőrizzük az adatok utolsó frissítésének dátumát és időpontját, valóban ideális, hogy bármi programozás nélkül átvegye az irányítást.
Ha ezt a phpMyAdminból szeretnénk definiálni, akkor csak az Attribútumokban kell kiválasztanunk a "frissítéskor" CURRENT_TIMESTAMP, és alapértelmezett értékként a CURRENT_TIMESTAMP opciót. Mező, amelynek értéke automatikusan frissíthető rekord beillesztésekor vagy módosításakor.
ÉV
Abban az esetben, ha látnunk kell, hogy egy mezőt ÉVnek kell definiálnunk, tárolhatunk egy évet, mindkettő, mind négy számjegy használatával. Abban az esetben, ha két számjegyben, 70 -től 99 -ig adjuk meg (70-99 -es számokkal megértjük, hogy ezek az 1970 és 1999 közötti évek tartományának felelnek meg, és ha 00 és 69 közötti számjegyekkel rendelkezünk, akkor megérthetjük Ez a 2000 és 2069 közötti évekre vonatkozik), a négy számjegy megadása esetén azt találnánk, hogy a lehetséges tartomány kibővül, majd 1901 -től 2155 -ig.
Van egy extra lehetőségünk is, bár nem kapcsolódik a MySQL adattípusaihoz, de dátumokhoz és időpontokhoz kapcsolódik. Ez az extra lehetőség egy időbélyeg érték előállítása a PHP time függvénnyel (ismét szeretnénk tisztázni, hogy már nem a MYSQL -ről beszélünk, bár a zavarás a teljesen hasonló nevek miatt érvényes).
Egyébként tárolhatjuk ezt az értéket egy 10 számjegyű INT mezőben, ily módon nagyon egyszerű lesz megrendelni a mezőnk értékeit (példaként felvehetjük egy hír dátumát), majd meg tudja mutatni ezt a dátumot, ha az érték időbélyegét olyasmivé alakítja át, amit a PHP saját dátumkezelő funkcióival olvashatóvá tudunk tenni.
Remélem, hogy ezzel a MySQL adattípusokról szóló cikkünkkel mindent, amit el akartunk magyarázni, kellően egyértelművé tudtuk tenni, és megtanulta, hogyan hozzon létre adatbázist és táblázatot minden információnk szerint, teljes pontossággal meghatározva a mezőiket. ezeknek az adatoknak és attribútumoknak a felhasználásával, tehát abban a képességben vagy körülmények között, hogy megfelelően elkezdhessük a programozást, most már világos elképzelésünk van arról, hogy pontosan milyen formátumra lesz szükségünk, amely megfelel az igényeinknek. programozni kell.
Meghívjuk Önt, hogy olvassa el a programozással kapcsolatos másik cikkünket: Polimorfizmus az objektum-orientált programozásban.