I am trying to set the length to infinity of one of the field of my database table whose data type is integer (BIGINT). Kindly let me know how can I set the length of the field to infinity/unlimited?
Column Type Collation Attributes Null Default Extra Action
1 id bigint(255) No None AUTO_INCREMENT
You cannot. All *INT fields have a fixed length that directly relates to the size of integers in various programming languages (and in particular, C). Even DECIMAL has a maximum size. If you need larger than it provides then use one of the *TEXT fields to hold the value as a string, but be aware that even those have limitations.
For maximum values take a look at documentation
BIGINT SIGNED - 9223372036854775807
BIGINT UNSIGNED - 18446744073709551615
mysql> CREATE TABLE Table1(`col1` BIGINT, `col2` BIGINT UNSIGNED);
Query OK, 0 rows affected (0.02 sec)
mysql> DESC table1;
+-------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------------------+------+-----+---------+-------+
| col1 | bigint(20) | YES | | NULL | |
| col2 | bigint(20) unsigned | YES | | NULL | |
+-------+---------------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
mysql> INSERT INTO Table1 VALUES(9223372036854775807, 18446744073709551615);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM Table1;
+---------------------+----------------------+
| col1 | col2 |
+---------------------+----------------------+
| 9223372036854775807 | 18446744073709551615 |
+---------------------+----------------------+
1 row in set (0.00 sec)
I think it is not allowed in DBMS, but some DBMS like MSDE 2000 can accept the infinite float value. but it is a fatal error if you save this value.
i mean are sure your application needs such kind of data without having no errors. ?
BIGINT range is:
-9223372036854775808 to 9223372036854775807 normal. 0 to 18446744073709551615 UNSIGNED*.
The maximum number of digits may be specified in parenthesis
if you query this infinite OR NaN data , your DB may corrupt or throw a fatal error.
That is why it is recommned to better use Exceptional handling before querying if you have no idea about the stored data.
Related
How can I make MySQL auto increment in 4 digit format?
So instead of '1' make '0001'?
Try adding ZEROFILL attribute to the field.
Could you leave it as an integer and format it for humans in your SQL, for example, to pad with zeros to 4 chars wide
select lpad(idcolumn,4,'0') from mytable;
Or use zerofill and specify the desired width when declaring the table:
create table tmpfoo (
mykey int(6) zerofill not null auto_increment,
primary key(mykey)
);
insert into tmpfoo values(1),(2);
select * from tmpfoo;
+--------+
| mykey |
+--------+
| 000001 |
| 000002 |
+--------+
MySQL supports ZEROFILL on integer columns:
mysql> create table foo (the_key int unsigned zerofill not null
auto_increment primary key);
Query OK, 0 rows affected (0.21 sec)
mysql> insert into foo SET the_key = Null;
Query OK, 1 row affected (0.00 sec)
...
mysql> insert into foo SET the_key = Null;
Query OK, 1 row affected (0.00 sec)
mysql> select * from foo;
+------------+
| the_key |
+------------+
| 0000000001 |
| 0000000002 |
| 0000000003 |
| 0000000004 |
| 0000000005 |
| 0000000006 |
| 0000000007 |
| 0000000008 |
+------------+
8 rows in set (0.00 sec)
You may need to look into using a smallint (5 digits), or trimming/padding.
If you need the auto_increment column in a zero padded format, I suggest that you display it as such and not attempt to store it in the database that way.
In PHP, you could use the following code to display or otherwise use the id:
$padded_id = str_pad($id, 4, '0');
To pad in the database set the id column to ZEROFILL
But if its for display purposes only I recommend using LPAD
SELECT RIGHT('000000' + yourNum, 6);
is the field an integer? if so, the answer is, "why? it's an integer!" ;-)
I am using MySQL client of version 5.5. Today I tried "NOT NULL" to set an attribute, only find it doesn't work during my test. Anybody helps explain this?
//Create Table
CREATE TABLE state(
state_cd char(2) NOT NULL,
state_name varchar(30)
);
//Insert an "Invalid" Record
INSERT INTO state(state_name)
values('Massachusetts');
//DB Operation succeeds!!!
Query OK, 1 row affected, 1 warning (0.09 sec)
//Check the table
mysql> select * from state;
+----------+---------------+
| state_cd | state_name |
+----------+---------------+
| | Massachusetts |
+----------+---------------+
1 row in set (0.00 sec)
mysql> describe state;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| state_cd | char(2) | NO | | NULL | |
| state_name | varchar(30) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
If you try to insert or update a NOT NULL column to NULL, MySQL will set it to the default instead (in this case the de-facto default is empty string). MySQL will also issue a warning that you can see with SHOW WARNINGS that should say something about an incorrect column value. It will not prevent you from attempting to insert a null value, but it will not accept the value.
You may want to specify an explicit default value
state_cd char(2) NOT NULL DEFAULT '--'
If you want the query to fail when attempting you can either handle this at the application level or take a look at MySQL server modes, which you can set to TRADITIONAL so INSERT/UPDATE will fail when attempting to add an incorrect value.
I have created a table with an UTF-8 VARCHAR(5000), and filled it with data.
But it looks like this field is allowing more data than it is instructed to:
mysql> DESCRIBE test;
+---------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| comment | varchar(5000) | YES | | NULL | |
+---------+------------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)
mysql> SELECT MAX(LENGTH(comment)) FROM test;
+----------------------+
| MAX(LENGTH(comment)) |
+----------------------+
| 5001 |
+----------------------+
1 row in set (0.01 sec)
Why is that?
Ok, the problem is that LENGTH() returns the length in bytes, not chars. Because the string is UTF-8, I need to use CHAR_LENGTH() instead:
mysql> DESCRIBE test;
+---------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| comment | varchar(5000) | YES | | NULL | |
+---------+------------------+------+-----+---------+----------------+
2 rows in set (0.01 sec)
mysql> SELECT MAX(LENGTH(comment)) FROM test;
+----------------------+
| MAX(LENGTH(comment)) |
+----------------------+
| 5001 |
+----------------------+
1 row in set (0.01 sec)
mysql> SELECT MAX(CHAR_LENGTH(comment)) FROM test;
+----------------------+
| MAX(LENGTH(comment)) |
+----------------------+
| 5000 |
+----------------------+
1 row in set (0.01 sec)
The length was 5001 because the string contained exactly one two-byte character!
The following table illustrates the differences between CHAR and VARCHAR
by showing the result of storing various string values into CHAR(4) and
VARCHAR(4) columns (assuming that the column uses a single-byte character
set such as latin1).
Value |CHAR(4) |Storage Required |VARCHAR(4) |Storage Required
===================================================================================
'' ' ' 4 bytes '' 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes
===================================================================================
The values shown as stored in the last row of the table apply only when
not using strict mode; if MySQL is running in strict mode, values that exceed
the column length are not stored, and an error results.
The effective maximum length of a VARCHAR is 65,535 bytes. The number 5,000 you had created the VARCHAR column with, does not actually limit the length of the allowable storage for VARCHAR column. This is a different behavior as compared with CHAR data type.
11.4.1. The CHAR and VARCHAR Types
would it be that 5000 starts at zero, then counts on giving you 5001 chars.
Does it do 5002 ?
I knew boolean in mysql as tinyint (1).
Today I see a table with defined an integer like tinyint(2), and also others like int(4), int(6) ...
What does the size means in field of type integer and tinyint ?
The (m) indicates the column display width; applications such as the MySQL client make use of this when showing the query results.
For example:
| v | a | b | c |
+-----+-----+-----+-----+
| 1 | 1 | 1 | 1 |
| 10 | 10 | 10 | 10 |
| 100 | 100 | 100 | 100 |
Here a, b and c are using TINYINT(1), TINYINT(2) and TINYINT(3) respectively. As you can see, it pads the values on the left side using the display width.
It's important to note that it does not affect the accepted range of values for that particular type, i.e. TINYINT(1) still accepts [-128 .. 127].
It means display width
Whether you use tinyint(1) or tinyint(2), it does not make any difference.
I always use tinyint(1) and int(11), I used several mysql clients (navicat, sequel pro).
It does not mean anything AT ALL! I ran a test, all above clients or even the command-line client seems to ignore this.
But, display width is most important if you are using ZEROFILL option, for example your table has following 2 columns:
A tinyint(2) zerofill
B tinyint(4) zerofill
both columns has the value of 1, output for column A would be 01 and 0001 for B, as seen in screenshot below :)
mysql> CREATE TABLE tin3(id int PRIMARY KEY,val TINYINT(10) ZEROFILL);
Query OK, 0 rows affected (0.04 sec)
mysql> INSERT INTO tin3 VALUES(1,12),(2,7),(4,101);
Query OK, 3 rows affected (0.02 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM tin3;
+----+------------+
| id | val |
+----+------------+
| 1 | 0000000012 |
| 2 | 0000000007 |
| 4 | 0000000101 |
+----+------------+
3 rows in set (0.00 sec)
mysql>
mysql> SELECT LENGTH(val) FROM tin3 WHERE id=2;
+-------------+
| LENGTH(val) |
+-------------+
| 10 |
+-------------+
1 row in set (0.01 sec)
mysql> SELECT val+1 FROM tin3 WHERE id=2;
+-------+
| val+1 |
+-------+
| 8 |
+-------+
1 row in set (0.00 sec)
About the INT, TINYINT... These are different data types, INT is 4-byte number, TINYINT is 1-byte number. More information here - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT.
The syntax of TINYINT data type is TINYINT(M), where M indicates the maximum display width (used only if your MySQL client supports it).
Numeric Type Attributes.
Is it possible to store a MySQL AES_ENCRYPT into a LONGTEXT column?
I know I'm suppose to use varbinary or blob, but I have a table that I'm storing a bunch of random "settings" in, and the settings_value column is longtext.
I went to store a "smtp mail password" in there, and got a little stuck.
If not, I guess, I'll store it as a hex string through php.
SOLUTION:
My query was something like this:
INSERT INTO table (setting_value)VALUES(AES_ENCRYPT('password', 'key')) ON DUPLICATE KEY UPDATE setting_value=VALUES(setting_value)
As you will see in my comments below, I tried changing my column encoding from utf8_unicode_ci to utf8_bin and still it failed. I changed to latin1_bin and it worked.
I switched back to utf8_unicode_ci and changed my query to the following:
INSERT INTO table (setting_value)VALUES(HEX(AES_ENCRYPT('password', 'key'))) ON DUPLICATE KEY UPDATE setting_value=VALUES(setting_value)
That worked since it just turned my value into a hex string.
Took me a second to figure out how to get the value back out correctly, so for documentation purposes:
$pass = SELECT AES_DECRYPT(BINARY(UNHEX(setting_value)), 'key') as orig_text FROM table
echo $pass->orig_text
Did you try it? It's pretty easy to set up a test case, and from what I can see it works fine for your requirements:
mysql> create table t (id int unsigned not null auto_increment primary key, str LONGTEXT);
Query OK, 0 rows affected (0.13 sec)
mysql> desc t;
+-------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| str | longtext | YES | | NULL | |
+-------+------------------+------+-----+---------+----------------+
2 rows in set (0.05 sec)
mysql>
mysql> INSERT INTO t VALUES (1,AES_ENCRYPT('text','password'));
Query OK, 1 row affected (0.02 sec)
mysql>
mysql> select id,str,AES_DECRYPT(str,'password') from t;
+----+-----------------------------+-----------------------------+
| id | str | AES_DECRYPT(str,'password') |
+----+-----------------------------+-----------------------------+
| 1 | ö½¨Ü·øÍJ/ª¼Tf€D | text |
+----+-----------------------------+-----------------------------+
1 row in set (0.00 sec)
Use some binary column type (like BLOB instead of LONGTEXT) for storing AES_ENCRYPTed content.