So I created a table with all varchar (255) then decided to use CAST to change to UNSIGNED (since all +ve values). When I checked, it has been changed to unsigned. However, I noticed when I check the whole table again the columns are still considered as varchar.
Is my understanding correct that CAST only works for the specific code and will not permanently change and if I wish to change the column type permanently, will require me to use ALTER as shown below?
If so why do people use cast instead of Alter?
CREATE table project.worldcup_players (
MatchID varchar (255),
Team_Initials varchar (255),
Coach_Name varchar (255),
Player_Name varchar (255)
);
SELECT * FROM project.worldcup_players;
SELECT CAST(MatchID AS UNSIGNED) AS MatchID FROM project.worldcup_players;
ALTER TABLE project.worldcup_players
CHANGE COLUMN `MatchID` `MatchID` INT NULL DEFAULT NULL ;
CAST only changes the result of an expression in the query. You could use CAST if you only want to change to an unsigned integer sometimes, without changing the way the data are stored.
ALTER TABLE is required if you want to change the way the data are stored.
Suppose your MatchID was represented by a number only for some matches. In other matches, the match is identified by an alpha string. In that case, the column must be a varchar, because the column must be stored as the same data type on all rows in a given table. Don't alter the table, because it would cause all the non-numeric strings to be changed to their numeric equivalent, 0.
Related
I'm new to this website and using Mysql and phpMyAdmin. I need help with one of my table and I would really appreciate it. So, I created a table that has an Integer column I want to be able to limit it to only 7(Seven) digits I'm not quiet sure if this is possible using Mysql or phpMyAdmin.
I haven't tried any query on it. I want to limit the Integer type to only 7(Seven) digits.
This might not be the best possible solution but I think that if you were to store the integer as string in the format char(7) to limit the number of characters able to be entered it would get the job done.
I'm not familiar with Mysql in particular but here's some documentation on it : https://dev.mysql.com/doc/refman/8.0/en/char.html
I hope this helped.
In MySQL <8.0.16 You can't restrict the number of digits for an Integer. That has no meaning.
You can, however, use a DECIMAL type that allows you to specify the number of digits and the number of decimal places.
For example, DECIMAL(7,0) will define what you want.
Your CREATE statement becomes something like
CREATE TABLE IF NOT EXISTS myTable (
id INT AUTO_INCREMENT PRIMARY KEY,
someText VARCHAR(255) NOT NULL,
decimalValue DECIMAL(7,0)
) ;
If you're using MySQL 8.0.16 or later you can use a CHECK constraint to limit the value (as distinct from limiting the number of digits).
The example above becomes
CREATE TABLE IF NOT EXISTS myTable (
id INT AUTO_INCREMENT PRIMARY KEY,
someText VARCHAR(255) NOT NULL,
decimalValue INT,
CONSTRAINT `decValue_chk` CHECK (`decimalValue` <= 9999999))
) ;
In mysql workbench, I created a new table and added a column id, and by default its datatype is set to INT, PK and NN boxes are selected. When I tried to change the datatype of id column to VARCHAR(), it gave the following error:
What is wrong?
change varchar() it to varchar(10) I believe you are missing the width of varchar
varchar() is an empty statement, seeking the width of the "string" that you are setting. You have to input the amount of characters to accept. (Ex: varchar(10) or varchar(45)).
I've seen a similar question on stackexchange, but it's answer did not give me the correct results.
For demonstration purposes, I have a simple table PURCHASES with columns PURCHASE_NUM, PURCHASE_DATE, CUSTOMER_ID. I want to enforce a not null constraint on the CUSTOMER_ID table. I tried the following:
ALTER TABLE PURCHASES MODIFY CUSTOMER_ID char NOT NULL;
That syntax is fine, but then I insert with the following: INSERT INTO PURCHASES VALUES (333, NULL, NULL); and the tuple is added without issue. Why is the constraint not being enforced? Would having NULL values already in that column before adding the constraint affect things?
Thanks
edit DESCRIBE PURCHASES; says the following for the column of interest:
Field, Type, Null, Key, Default, Extra
CUSTOMER_ID, char(5), YES, , NULL,
Your ALTER command didn't work, the Null column still says YES. Your ALTER command syntax looks just fine, it should have worked. Check your typing and try again.
Is your customer ID really just a char?
Maybe you have to change to
ALTER TABLE PURCHASES MODIFY CUSTOMER_ID char NOT NULL;
According to the manual, data entry into a NOT NULL column that has no explicit DEFAULT clause will set the column to NULL. Thus, you should ALTER your column to contain a DEFAULT. From 4.0 documentation:
Implicit defaults are defined as follows:
For numeric types, the default is 0, with the exception that for integer or floating-point types declared with the AUTO_INCREMENT attribute, the default is the next value in the sequence.
For date and time types other than TIMESTAMP, the default is the appropriate “zero” value for the type. For the first TIMESTAMP column in a table, the default value is the current date and time. See Section 10.3, “Date and Time Types”.
For string types other than ENUM, the default value is the empty string. For ENUM, the default is the first enumeration value.
How can I limit my database column's integral input to a specific number of digits ?
CREATE TABLE tab (id INT <1 digit> not null, value INT <10 digits> not null);
Thank you
Add a check constraint (SQL Server) or trigger (MySQL, doesn't support CHECK constraints)
SQL Server example:
CREATE TABLE tab (
id tinynot null CHECK (id BETWEEN 0 AND 9),
value INT not null CHECK (id BETWEEN 1000000000 AND 9999999999)
);
If you only want one digit though, then use tinyint
If you aren't storing numbers (eg "123456789 bananas") but, say, phone numbers then use a varchar type. See https://stackoverflow.com/a/8284674/27535
Edit, you'd need a trigger in MySQL
The short version is using TINYINT UNSIGNED NOT NULL will be a more suitable data type, but it can't limit the values stored.
The longer version is that you may wish to read up on MySQL integer data types. You'll see that TINYINT is sufficient for your purpose as that is a 1-byte column that stores values from -128 to +127, or 0 to +255.
Secondly if you define it as TINYINT(1) then you are defining it as being a TINYINT with a display width of 1 digit. This will not prevent values larger than 10 being stored though. For more reading on this behaviour check numeric type attributes.
I just read the accepted answer of this question, which left me with this question.
Here's a quote from that answer:
"But since you tagged this question with MySQL, I'll mention a MySQL-specific tip: when your query implicitly generates a temporary table, for instance while sorting or GROUP BY, VARCHAR fields are converted to CHAR to gain the advantage of working with fixed-width rows. If you use a lot of VARCHAR(255) fields for data that doesn't need to be that long, this can make the temporary table very large."
As I understand it, the advantage of CHAR is that you get fixed-width rows, so doesn't a VARCHAR in the same table mess that up? Are there any advantages of using CHAR when you have a VARCHAR in the same table?
Here's an example:
Table with CHAR:
CREATE TABLE address (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
street VARCHAR(100) NOT NULL,
postcode CHAR(8) NOT NULL,
PRIMARY KEY (id)
);
Table without CHAR:
CREATE TABLE address (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
street VARCHAR(100) NOT NULL,
postcode VARCHAR(8) NOT NULL,
PRIMARY KEY (id)
);
Will the table with CHAR perform any better than the table without CHAR, and if so, in what situations?
"VARCHAR" basically sets a maximum length for the field and only stores the data that is entered into it, thus saving on space. The "CHAR" type has a fixed length, so if you set "CHAR(100)", 100 character worth of space will be used regardless of what the contents are.
The only time you will gain a speed advantage is if you have no variable length fields in your record ("VARCHAR", "TEXT", etc.). You may notice that Internally all your "CHAR" fields are changed to "VARCHAR" as soon as a variable length field type is added, by MySQL.
Also "CHAR" is less efficient from a space storage point of view, but more efficient for searching and adding. It's faster because the database only has to read an offset value to get a record rather than reading parts until it finds the end of a record. And fixed length records will minimize fragmentation, since deleted record space can be reused for new records.
Hope it helps.