INT Datatype in MySQL - mysql

Does the INT, TINYINT, MEDIUMINT, BIGINT in MySQL Accepts the character '-' ? I used the data type INT in a column and the data inside has the character '-'. And somehow it didn't accept it. If it's not possible for INT data types, should I use VARCHAR?

The values for an integer in SQL are:
-2147483648 through 2147483647
And the byte size is 4 bytes.
Other maximum values:
BigInt: -9223372036854775808 through 9223372036854775807 (8 bytes)
SmallInt: -32768 through 32767 (2 bytes)
TinyInt: 0 through 255 (1 byte)
it dosent accept any char or string values like "-"
use varchar datatype if u want to insert "-"

Use VARCHAR(45) or TEXT datatype, if you want to insert characters.

you have to use Varchar DataType for this.
It will support both Int and Special Symbol like '-'
If you are not going to do any arithmetic operaion means then you can
use Varchar or text DataType

Related

Mysql Column Definition Set Max limit

I was wondering if I can set a max value in column definition of MySQL, just like we set a default value during column definition. If it can be done, how can it be achieved ? Example format:
int(5) not null default 1 <Something to set max value> ??
In table definition, you can only specify maximum number of characters, for example, when you specify a column as int(5), you are limiting the field to 5 bits.
Please refer to the documentation.
To make sure the column will not accept an integer greather that 50 for exeample, you will need to use triggers for example:
CREATE TRIGGER check_trigger
BEFORE INSERT
ON table
FOR EACH ROW
BEGIN
IF NEW.age<0 OR NEW.age>50 THEN
CALL `Error: Wrong values for age`; -- this trick will throw an error
END IF;
END
You can only control the max values of a column by changing the type.
If your minimum value desired is -128 and your max required is 127, then you can go with a TINYINT(). If you need between -32768 and 32767, then you need a SMALLINT(), and so on.
Source: MySQL Docs: Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT
Presuming you are dealing with "max" and "min" integers, for instance...
TINYINT : 1 byte, -128 to 127 signed, 0 to 255 unsigned
SMALLINT : 2 bytes, -32768 to 32767 signed, 0 to 65535 unsigned
MEDIUMINT : 3 bytes, -8388608 to 8388607 signed, 0 to 16777215 unsigned
INT : 4 bytes, -2147483648 to 2147483647 signed, 0 to 4294967295 unsigned
BIGINT : 8 bytes, -2^63 to 2^63-1 signed, 0 to 2^64-1 unsigned

When to use the different numeric data types - TINYINT / SMALLINT / MEDIUMINT / INT / BIGINT - MySQL

I read the answers given here: What is the difference between tinyint, smallint, mediumint, bigint and int in MySQL? , so I now know how they store the data, but I'm still not sure how to set my database up. For example, if I want a field to be either 0 or 1 (sort of binary, 0 = off, 1 = on), do I use TINYINT with a length of 1?
My main question is, what does the LENGTH setting determine? As each NUMERIC data type already has their own associated data size.
Also, what is the difference between SIGNED and UNSIGNED, and why should I choose one over the other?
http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html
Diffrence between SIGNED and UNSIGNED is with UNSIGNED you can store only positive numbers.
For example :
about INT (Normal INTEGER) values
The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.
If you are using PK auto_increment value then you should use UNSIGNED in this case.
http://dev.mysql.com/doc/refman/5.0/en/integer-types.html
This shows storage and range for each INTEGER types.
For binary fields use BIT.
the length of numerics specifies the precision before and after the comma. See here
An integer variable has 32 bits to store the integer value.
In signed integer the first bit is reserved to store positive or negative sign. So, a signed integer can use only 31 bits to store a value and hence its range will be −2,147,483,648 to +2,147,483,647.
Suppose if your program needs to store only positive integer greater than +2,147,483,647. You need to consider the long integer that will take 8 bits that will cause the wastage of memory.
Instead you can go with unsigned integer. In an unsigned integer no bit is reserved for the sign so now you have 32 bits to store the value. The only limitation with an unsigned integer is that you cannot use it to store negative values. The range of an unsigned integer of 32 bits will be 0 to 4,294,967,295.
Hope it clears your concept of signed and unsigned integer.

Is there a difference in using INT(1) vs TINYINT(1) in MySQL?

I'm under the assumption that INT(1) is the exact same thing as TINYINT(1) but I really have no idea. Whenever I've had values that can only be a single integer (e.g. a value 0-9), I've always just used INT(1) to say it's an integer and it will only be one character, which I assume means that it could only be a value 0 through 9 (please explain this to me if I'm wrong). I've always just ignored the other types of INT that you can cast the number as. I'm no MySQL savvy and tend to avoid the more complicated things you can do with it.
So my question, is there any difference between the various integer types INT, TINYINT, SMALLINT, MEDIUMINT, and BIGINT if you define a length of 1 for each type;? If not, should I use them anyways (I can see using them for more semantic meaning, TINYINT being more specific than just INT)? If so, could I easily (and/or should I) just go through my database and change all my INT(1) fields to TINYINT(1) fields?
Here you'll understand it in a better way!
tinyint: 1 byte, -128 to +127 / 0 to 255 (unsigned)
smallint: 2 bytes, -32,768 to +32,767 / 0 to 65,535 (unsigned)
mediumint: 3 bytes, -8,388,608 to 8,388,607 / 0 to 16,777,215 (unsigned)
int/integer: 4 bytes, -2,147,483,648 to +2,147,483,647 / 0 to 4,294,967,295 (unsigned)
bigint: 8 bytes, -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 / 0 to 18,446,744,073,709,551,615 (unsigned)
The number in parentheses for integer column types is the "display width". This does not effect the storage requirements as they are pre-defined.
Further reading
http://dev.mysql.com/doc/refman/5.0/en/data-types.html
http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
To summarize the accepted answered :
The number in parentheses indicates the *number of characters to display that field*, **not** the storage size of the field.
But if you want to know the storage size, you should check the MySQL source documents.
Source: MySQL Docs: Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT
Direct quote from source documentation :
TINYINT : 1 byte, -128 to 127 signed, 0 to 255 unsigned
SMALLINT : 2 bytes, -32768 to 32767 signed, 0 to 65535 unsigned
MEDIUMINT : 3 bytes, -8388608 to 8388607 signed, 0 to 16777215 unsigned
INT : 4 bytes, -2147483648 to 2147483647 signed, 0 to 4294967295 unsigned
BIGINT : 8 bytes, -2^63 to 2^63-1 signed, 0 to 2^64-1 unsigned

varchar(255) vs tinytext/tinyblob and varchar(65535) vs blob/text

By definition:
VARCHAR: The range of Length is 1 to 255 characters. VARCHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given. x+1 bytes
TINYBLOB, TINYTEXT: A BLOB or TEXT column with a maximum length of 255 (2^8 - 1) characters x+1 bytes
So based on this, I creaate the following table:
CREATE TABLE `user` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255),
`lastname` tinytext,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
Or is it better to create a varchar or tinytext and why?
Is it the same for:
VARCHAR: The range of Length is > 255 characters. VARCHAR values are sorted and compared in case-insensitive fashion unless the BINARY keyword is given. x+2 bytes
BLOB, TEXT A BLOB or TEXT column with a maximum length of 65535 (2^16 - 1) characters x+2 bytes
In this case varchar is better.
Note that varchar can be from 1 to 65535 chars.
Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions. The effective maximum length of a VARCHAR in MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used. See Section E.7.4, “Table Column-Count and Row-Size Limits”.
Blobs are saved in a separate section of the file.
They require an extra fileread to include in the data.
For this reason varchar is fetched much faster.
If you have a large blob that you access infrequently, than a blob makes more sense.
Storing the blob data in a separate (part of the) file allows your core data file to be smaller and thus be fetched quicker.

Representing n-bit unsigned integers in mysql

How do I represent this data in mysql?
16 bit unsigned integer -----Range: 0x0000 - 0xFFF7
64 bit unsigned int. Depicted as xx:xx:xx:xx:xx:xx:xx:xx -----Range: 0x0000 - 0xFFFFFFFFFFFFFFFF
2 bits ----- 00 - None, 01 - Residential Security, 10 - High Security
32 bit unsigned int
Should I convert everything to string and convert it at application layer?
According to MySQL's Overview of Numeric Types:
UNSIGNED SMALLINT: range is 0 to 65535. This would be sufficient for 16-bit unsigned ints.
UNSIGNED TINYINT: range is 0 to 255. Sufficient for 2-bit unsigned int. It appears you would need to preserve leading zeroes, so use ZEROFILL too. To keep the value to just two characters wide, you can specify UNSIGNED ZEROFILL TINYINT(2).
UNSIGNED INT: range is 0 to 4294967295. Sufficient for 32-bit unsigned int.
UNSIGNED BIGINT: range is 0 to 18446744073709551615. See below:
The last one, the 64-bit unsigned int, has a couple of caveats, from the above linked page:
All arithmetic is done using signed BIGINT or DOUBLE values, so you should not use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting a BIGINT value to a DOUBLE.
You can always store an exact integer value in a BIGINT column by storing it using a string. In this case, MySQL performs a string-to-number conversion that involves no intermediate double-precision representation.
The -, +, and * operators use BIGINT arithmetic when both operands are integer values. This means that if you multiply two big integers (or results from functions that return integers), you may get unexpected results when the result is larger than 9223372036854775807.
MySQL support several data types. See MySQL Data Types
UNSIGNED BIGINT : 8-byte (64-bit) integer
UNSIGNED INT : 4-byte (32-bit) integer
UNSIGNED SMALLINT : 2-byte (16-bit) integer
For the 2-bit type, you may use the TINYINT (8-bit) or the ENUM datatype.