I'm not much experienced in SQL and I need to modify my tables as follows but cannot work out how to do so.
I have a MySQL database with multiple tables where some of the columns have type e.g. DECIMAL(17, 2) and I need to change the type to have at least 4 decimal places as effectively as possible.
Can someone help me with this please?
Thank you in advance.
You can only do it via the ALTER that #Barranka suggests. However, there are two enhancements:
MODIFY all the COLUMNs in a single table in a single ALTER; this will run faster.
You could write a Stored Procedure to read information_schema.COLUMNS to discover which tables have DECIMAL(xx,2) and create the ALTERs for you.
But, why do you want 4 decimal places? If you are that loosy-goosy about the precision of the numbers, perhaps FLOAT or DOUBLE would suffice?
You can change the column definitions with ALTER TABLE. Example:
alter table your_table
modify column a_number decimal(19,4);
In this example, I'm enhancing the column a_number so it holds now a number of length 19 with 4 decimal places. You need to increase the length of the column, not just the decimal places, because if you have numbers with 17 digits (including 2 decimals), you may loose some values if you don't increase the length.
Check the reference manual for ALTER TABLE.
Related
I'm somewhat confused on defining the correct definition for a float table column. This is required to create a database table to store large numbers which have up to eight decimal places. I need to be able to store anywhere from and between the following two.
0.00000001 - 10000000
Would that be defined as float(16) as the argument is the maximum number of digits that need to be displayed. Perhaps I have misunderstood the column definition entirely.
FLOAT is approximate datatype and I would not recommend it to use for storing exact values.
For storing exact numbers you should use DECIMAL datatype:
CREATE TABLE tab(col DECIMAL(20,10));
Should be more than sufficent for your needs.
How do you update a MySql database bigint field?
Currently our database has a bigint(196605) field which is generating errors. I am pretty sure the field limit is 250 i.e. bigint(250) which explains the errors being generated.
The field itself only stores integer values 3 digits e.g. 100, so I am not sure why it is even bigint. In any case, I need to fix the field without any loss of data.
Any help would be most appreciated!
This is a common confusion ... BIGINT type has a fixed size is stored on 8B so the ONLY difference between BIGINT(1) and BIGINT(20) is the number of digits that is gonna be displayed 1 digit respectively 20 digits .
If you store only 3 digits numbers ,and you do not think you will need more you can use a SMALLINT UNSIGNED type which takes only 2B instead of 8B so you will save a lot of space and the performance will increase.
I suggest you read this first.
May be when creating database field, you set its length, if we do not set any length then I think it takes 11 as default. but If we pass then it will take specified value as length.
Before you do something, export (backup) your data into an SQL file (autogenerated inserts for your data) to save your data before you change your table and you know that if your data is lost, you can import it.
If you want to change your column, you must update your table like this:
ALTER TABLE tableName CHANGE columnName newColumnName BIGINT(250);
I think this should work.
DIDN'T TESTED (I use MS SQL Server 2008 and can't check if it works)
I need to save in one MySql field two numeric values, a and b.
Both are natural numbers with a maximum of 11 characters, and they are going to be used in the next SQL structure.
"SELECT FROM table WHERE field=a and foild=b"
I thought about the next two possibilities:
Create a DECIMAL with {11},{11} range.
Create a VARCHAR with 23 chars and save them as "a.b" string.
Which is the best option? Is there any better option to get it work fast?
When saying fast I mean also the "cheapest" way to get a and b work in my query. Both examples would need a split process before using them, and I do not know if there is any way of doing this directly in one Query, having a and b as curiousfield.part1 and curiousfield.part2...
Thanks, (excuse me if curiousfield was too fantastic)
EDIT:
Why do I want to store multiple values in One column?
Because I have the next tables:
int-value
content [INT]
varchar-value
content [VARCHAR (100)]
text-value
content [TEXT]
magic-value
content [????]
It is always being saved in "content" for many reasons, and making "magic-value" table to have content-a and content-b fields, would not be a nice solution in the requirements I am working with.
No, no, no!
Don't ever store multiple values in one column. Period.
you cannot save two decimal values in a column and which the data type of the column is decimal, it is better store it as two columns with data type of decimal than a column which values are separated by a comma.
It is much easy to search with using two numeric columns than a column with comma separated value.
If you want to store nature number in DB than store in decimal or integer.
If you store as integer
Retrieval is easy.
you can do manipulation or calculation on them in sql itself.
If you store in a single field, the above benefit you cant get and more over you need to split /concatenation it whenever you are saving or retrieving from db.
I have a table with all columns of type varchar, but the data are actually numbers, i.e. decimal(6,2) would be more appropriate. How can I change all columns from varchar to decimal if there are a lot of columns.
Thanks a lot in advance for your help.
You can change an individual column to decimal by using ALTER TABLE tablename MODIFY COLUMN columnname DECIMAL(6,2); . Any strings that can be converted to numbers will be converted, and others will be changed to zero.
If you want to be certain of doing this non-destructively, you could instead do ALTER TABLE ADD COLUMN to add a decimal column, and then UPDATE tablename SET decimalcolumn = textcolumn , and then use a SELECT to check for any rows where textcolumn and decimalcolumn aren't equal (it does type conversion as part of the comparison, so "5" and 5.00 are equal, as you'd want).
I don't know of a way to automatically apply the same conversion to multiple columns at once, though you could do it in PHP or another programming language by selecting a row from the table, looping over the columns that are returned, and running MODIFY for each one. If there are only a few columns, it's probably easier to do it by hand.
MySQL's ALTER TABLE statement supports changing multiple columns at once. In fact, doing as many changes to a table's schema as you can in one statement is preferred and highly recommended. This is because MySQL copies the whole table to do a schema change, but only does the copy once per ALTER TABLE statement. This is an important time saver when modifying a very large table!
That said, you can rehearse your changes in a couple of ways.
Firstly, I would use a development database to test all this, not a production one. You can then use CREATE TABLE ... LIKE ... to create a structurally identical table and then use INSERT INTO ... SELECT * FROM ... to copy the data. Now you can experiment with ALTER TABLE ... MODIFY COLUMN ... DECIMAL(6,2). If you do this on one column and get the message 0 Warnings, then that column will convert without incident and you can test the next. If you do get warnings, then SHOW WARNINGS will show a number of them so you know what problem MySQL encountered.
Depending on how well you know the data, you can also do a number of different SELECTs to find and filter it to see how much of it might be out of range or unconvertable (e.g. blank or text instead of numbers).
Yes, this approach will take some time, but once you're happy with this, you can assemble all the MODIFY COLUMN clauses into the one statement and run it on the real table.
I've been inserting some numbers as INT UNSIGNED in MySQL database. I perform search on this column using "SELECT. tablename WHERE A LIKE 'B'. I'm coming across some number formats that are either too long for unsigned integer or have dashes in them like 123-456-789.
What are some good options for modifying the table here? I see two options (are there others?):
Make another column (VARCHAR(50)) to store numbers with dashes. When a search query detects numbers with dashes, look in this new column.
Recreate the table using a VARCHAR(50) instead of unsigned integer for this column in question.
I'm not sure which way is the better in terms of (a) database structure and (b) search speed. I'd love some inputs on this. Thank you.
Update: I guess I should have included more info.
These are order numbers. The numbers without dashes are for one store (A), and the one with dashes are for Amazon (B; 13 or 14 digits I think with two dashes). A's order numbers should be sortable. I'm not sure if B has to be since the numbers don't mean anything to me really (just a unique number).
If I remove the dashes and put them all together as big int, will there be any decrease in performance in the search queries?
the most important question is how you would like to use the data. What do you need? If you make a varchar, and then you would like to sort it as a number, you will not be able to, since it will be treating it as string..
you can always consider big int, however the question is: do you need dashes? or can you just ignore them on application level? if you need them, it means you need varchar. in that case it might make sense to have two columns if you want to be able to for example sort them as numbers, or perform any calculations. otherwise probably one makes more sense.
you should really provide more context about the problem
Mysql has the PROCEDURE ANALYSE , which helps you to identify with your existing data sets. here's some example.
Given you are running query WHERE A LIKE 'B' mainly. You can also try full text search if "A" varies a lot.
I think option 2 makes the most sense. Just add a new column as varchar(50), put everything in the int column into that varchar, and drop the int. Having 2 separate columns to maintain just isn't a good idea.