sql >> Databasteknik >  >> RDS >> Database

Hur man väljer rätt datatyper

Eftersom ett typiskt företags datamängd har växt exponentiellt har det blivit ännu viktigare att optimera datalagring. Storleken på dina data påverkar inte bara lagringsstorlek och kostnader, den påverkar också frågeprestanda. En nyckelfaktor för att bestämma storleken på din data är den datatyp du väljer. Denna handledning kommer att förklara hur du väljer rätt datatyper.

Vad är datatyper?

Datatyper definiera vilken typ och vilken mängd data som kan lagras i ett givet fält (eller kolumn).

Överväg en försäljningstabell med dessa exempelposter:

Varje fält har sin egen typ och sitt eget värdeområde:

köptid :datum och tid för reansale_id :heltalsvärden som ökar med ett för varje ny reacustomer_id :heltalsvärden som ökar med ett för varje ny kundvaluta :text alltid i valutakoden med tre teckenamount_paid :monetära reella numeriska värden mellan 0,00 USD och 1 000,00 USDenhet :text, där värdena kan vara:'skrivbord', 'mobilapp' och 'mobilwebb'har_rabatt :boolesk där poster kan vara TRUE eller FALSE anteckningar :text, där posten kan vara lika lång som vad som är tillåtet i vårt agentinmatningsverktyg (250 tecken)

Typen av data (heltal, text, reella tal, etc...) och de möjliga värdeområdena (0 till 1 000; valfria 3 tecken; etc...) motsvarar specifika datatyper databaser .

Vilka är de möjliga datatyperna?

Olika databaser har olika datatyper tillgängliga, men de flesta passar in i dessa kategorier:

Numerisk:

  • heltal :för tal utan bråk. Kan vara signerad (tillåt positiva och negativa värden) eller osignerade (tillåt endast positiva tal). Används vanligtvis för ID-fält och antal av något
  • decimal(x,y) :för tal med bråk som kräver exakt precision. Kan vara signerad (tillåt positiva och negativa värden) eller osignerade (tillåt endast positiva tal). Används vanligtvis för monetära områden. Användaren anger antalet signifikanta siffror som är tillåtna totalt (x) och efter decimaltecknet (y) inom parentes
  • flyta/dubbla :för tal med bråk som inte kräver exakt precision. Kan vara signerad (tillåt positiva och negativa värden) eller osignerade (tillåt endast positiva tal). Används vanligtvis för alla reella tal utom monetära fält

Datum/tid:

datum :för datumvärden

  • tid :för tidsvärden
  • tidsstämpel / datumtid :för datum- och tidsvärden

Text:

  • tecken(n) :för teckensträngar med fast längd, där värdet inom parentes bestämmer den fasta storleken på varje post
  • varchar(n) :för teckensträngar med variabel längd, där värdet inom parentes dikterar den maximala tillåtna storleken för varje post

Boolesk:

  • boolesk :för booleska (sant/falskt) värden. Vissa databaser (som MySQL) har inte boolesk datatyp och konverterar istället booleska värden till heltal (1=TRUE, 0 =FALSE)

De flesta databaser erbjuder storleksvariationer för varje typ. Till exempel tillhandahåller MySQL dessa möjliga heltalsdatatyper:

Hur man väljer rätt datatyper

Den grundläggande strategin för att välja den bästa datatypen är att välja den minsta datatypen som matchar den typ av data du har och som tillåter alla möjliga värden för din data.

Till exempel customer_id i vår exempelförsäljningstabell finns ett heltal som börjar med 0. Idag har vårt fiktiva företag bara 15 000 kunder. Genom att använda MySQL heltalsdatatyptabellen från föregående avsnitt kan vi bli frestade att välja SMALLINT osignerad som datatyp, eftersom det är den minsta datatypen som accepterar våra nuvarande heltalsvärden från 0 till 15 000. Vi räknar dock med att nå 100 000 kunder under de kommande 6-12 månaderna. När vi går över 65 535 visas SMALLINT kommer inte längre att räcka. Ett bättre val är alltså MEDIUMINT osignerad, vilket borde täcka oss under de kommande åren.

Du kan låta din databas välja datatyper åt dig när du skapar din tabell med exempelposter. Detta kommer dock sällan att ge dig det bästa valet av datatyp. Att till exempel låta MySQL välja datatyperna för en försäljningstabell med de exempelvärden som visats tidigare ger flera problem.

De problem vi stöter på med de datatyper som MySQL automatiskt valts är:

  1. fel datatyp :du kommer inte att kunna använda fältet på det sätt som du förväntar dig. Till exempel att ha purchase_time som en sträng och inte en tidsdatatyp betyder det att du inte kommer att kunna utföra tidsoperationer (som att beräkna hur lång tid det har gått sedan köpet) på fältet
  2. för begränsad :MySQL kommer att ge fel när du försöker mata in värden som är större än vad datatypen tillåter. Vi kommer till exempel att få felmeddelanden om vi har en rea med en summa_paid på 100,00 USD eller mer eller en agent_comment som är längre än 65 tecken
  3. för konservativ :Även om ingenting kommer att bryta av att vara för konservativt med datatyper, kommer du att slösa med lagringsutrymme. Med våra exempeldata skulle vi kunna spara 15 % av lagringsutrymmet genom att använda de mindre konservativa föredragna alternativen

Hur smarta moderna databaser än är, ägarna av datan vet fortfarande bäst om vilken typ av data som lagras och vilka möjliga värden data kan ta inom en överskådlig framtid. Så du måste noggrant specificera datatyperna för vart och ett av dina fält.

Dokumentation om datatyper för olika vanliga databaser finns här:

  • MySQL
  • Amazon Redshift
  • Apache Hive
  • Teradata

Slutsats

För att din databas ska fungera korrekt och vara så optimerad som möjligt är det viktigt att noggrant välja datatyperna för varje fält i dina tabeller.


  1. Hur man returnerar frågeresultat som en kommaseparerad lista i MySQL

  2. Quickbooks ODBC-drivrutin

  3. Enklaste sättet att göra en rekursiv självanslutning?

  4. Ingen lämplig drivrutin hittades när de inkluderade de nödvändiga drivrutinerna med maven-assembly-plugin