When using MySQL, are there times that it would make sense to use a textual field (varchar, text, etc) instead of a numeric field (int, float, etc.) even if all data to be stored is numeric?
For example would it be better, faster or more efficient to store '5 digit zip code' data in a 5 char 'varchar' field rather than in an explicitly numeric field?
If yes, how can I determine when it is best to use a text field for numeric data?
I'm using InnoDB if relevant.
EDIT: I'm using a zipcode as an example above, but 'in general' when should choose a textual datatype over a numeric datatype when all data to be stored is numeric data.
Depends on how you are using the data. For Zip codes I would use a VARCHAR - simply because it is a part of an address and will not be using it for calculations. Also you may wish to include other countries in the future (in the UK we have post codes that are alpha numeric).
Ed's answer pretty much covers everything, as a general rule:
don't store numeric values in varchar columns - unless there are chances that other characters will have to be stored (examples are zip codes and phone numbers)
When you need computations/comparisons on the stored values, always use numerical data types (in string comparison 2 is bigger than 10)
Related
Is storing filename in varchar datatype column good? Is there other way on handling files for your software like creating a folder by numeric Id and just checking if a file exists in the folder in your application logic?
Thanks!
I suggest the file name should be varchar.
Having a numeric id is a good practice generally for performance in mysql. For instance, int max size is 4 bytes. But varchar max size goes upto 9-12 bytes. Varchar also uses different characters sets like utf etc which is why (some other reasons) it takes more space.
If the varchar will be 20 characters, and the int is 4, then if you
use an int, your index will have FIVE times as many nodes per page of
index space on disk... Which means that traversing the index will
require one fifth as many physical and/or logical reads.
It kind of both depends on your length of numeric id and filename char length. And also, having a numeric id might complicate the situation a bit for you. Because even minor changes in numeric values might change file names, or change in filenames might also change numeric values.
And also, remember you should write a script or do something when ever you enter a new file name. Something has to convert the file name to numeric id. If the filenames remains same always, may be a numeric id is a good option.
Finally, I would say it all depends on your application, size of table
(no of rows), length of file name, length of numeric id etc.
Which MySQL datatype would be preferable (the smallest amount of data needed) for storing blood types? In other words, storing one to two letters with the '+' or '-' symbol.
Thanks
It's highly dependent on your needs and wants. Personally, I'd probably go with assigning a numeric value to each type and using tinyint. However, if you want the rows more directly readable CHAR(3) or VARCHAR(3) might be more appropriate. In fact, this is one of the few rare cases where I would even suggest using an ENUM (as it is very very unlikely you'll ever need to add or remove from possible values).
I have a couple numeric fields which will be storing fixed length numeric values, I don't need to do any math on these fields or sorting by highest to lowest or anything like that, so I'm wondering if using the CHAR data type would be better than using a BIGINT?
If you have a fixed-width number and it fits in a decimal field, then use that data type. Something like decimal(15, 0) should give you want you want.
If the choice is between a fixed width character and a string, I would probably go with a string in this case. I find that char(15) makes more sense than storing a 15-digit number in a bigint field. This makes it clear that the field is really an identifier of some sort, rather than an actual number.
If the data is numeric, use a numeric field. You never know when your requirements will change and you'll need to do numeric processing on the field.
when i was a noob, I developed a website to store daily expenses, and the expenses was saved as varchar. now I want to just alter the structure of the database (with all the thousands data inside) to decimal (which i found out is the best way to store currency stuff). my question is, will all the expenses data be intact? or will it corrupt anything?
I'd suggest a layered approach:
Alter the database structure and add a decimal field.
Select the data from the database into the programming language of your choice.
Convert the data with the language, write a SQL-script to insert (or insert them directly).
Remove the VARCHAR field
Rename the DECIMAL field to the name the VARCHAR field had.
Depending on how many thousands do you have...? If you have constants decimals (always 2 decimals for example) then you can change the type to decimal(8,2) 6 integers and 2 decimals. If the data have less than 2 decimal 2.1 => 2.10 but in the other hand if you have more than 2 decimals then it will be 2.118 => 2.11 So be careful with this.
Make some CAST test, you may want to read this question: Problem convert column values from VARCHAR(n) to DECIMAL
In Access 2003 I need to display numbers like this while keeping the leading zeroes:
080000
090000
070000
What data type should I use for this?
Use a string (or text, or varchar, or whatever string variant your particular RDBMS uses) and pad it with whatever character you want ("0") that you need.
Key question:
Are the leading zeros meaningful data, or just formatting?
For instance, 07086 is my zip code, and the leading zero is meaningful, so US zip codes have to be stored as text.
Are the values '1', '01', '001' and '0001' considered to be unique, legal values or are they considered to be duplicates?
If the leading zero is not meaningful in your table, and is just there for formatting, then store the data as a number and format with leading zeros as needed for display purposes.
You can use the Format() function to do your formatting, as in this example query:
SELECT Format(number_field, "000000") AS number_with_leading_zeroes
FROM YourTable;
Also, number storage and indexing in all database engines I know of are more efficient than text storage and indexing, so with large data sets (100s of thousands of records and more), the performance drag of using text data type for numeric data can be quite large.
Last of all, if you need to do calculations on the data, you want them to be stored as numbers.
The key is to start from how the data is going to be used and choose your data type accordingly. One should worry about formatting only at presentation time (in forms and reports).
Appearance should never drive the choice of data types in the fields in your table.
If your real data looks like your examples and has a fixed number of digits, just store the data in a numeric field and use the format/input mask attributes of the column in Access table design display them with the padded zeros.
Unless you have a variable number of leading zeros there is no reason to store them and it is generally a bad idea. unecessarily using a text type can hurt performance, make it easier to introduce anomalous data, and make it harder to query the database.
Fixed width character with Unicode compression with a CHECK constraint to ensure exactly six numeric characters e.g. ANSI-92 Query Mode syntax:
CREATE TABLE IDs
(
ID CHAR(6) WITH COMPRESSION NOT NULL
CONSTRAINT uq__IDs UNIQUE,
CONSTRAINT ID__must_be_ten_numeric_chars
CHECK (ID ALIKE '[0-9][0-9][0-9][0-9][0-9][0-9]')
);
Do you need to retain them as numbers within the table (i.e. do think you will need to do aggregations within queries - such as SUM etc)?
If not then a text/string datatype will suffice.
If you DO then perhaps you need 2 fields.
to store the number [i.e. 80000] and
to store some meta-data about how the value needs to be displayed
perhaps some sort of mask or formatting pattern [e.g. '000000'].
You can then use the above pattern string to format the display of the number
if you're using a .NET language you can use System.String.Format() or System.Object.ToString()
if you're using Access forms/reports then Access uses very similar string formatting patterns in it's UI controls.