I have an INT field in a large MySQL database containing incremental numbers in an INT field. These numbers are currently regular autoincrement numbers (1, 2, 3) but I need to pad them to three digits with zeroes at the beginning (so I get 001, 002, 003.. 010, 011, etc).
What commands can I run on my database to change this column into the format I need?
You can add a ZEROFILL attribute to the column to pad the data in the database or, when querying,
SELECT LPAD(CONVERT(`col`,VARCHAR(3)),3,'0')
to retreive the data formatted as a 3 digit number
There is no such thing as having leading zeroes on data in a numeric field in the database; the data just isn't stored that way, any more than it is stored in roman numerals. All you've got is the number three; so if you want to get the string "003" out, you've got two options:
Change to use a string field in the database: not recommended because you can't easily get incrementing numbers.
Format the number as you retrieve it from the database to add leading zeroes: better, but it has its own disadvantages - e.g. comparisons will be slower because they aren't indexed.
Related
I'm using MySQL 5.6, I want to declare such type of DATATYPE in a Field during table creation which accepts only Alphabets not Number, For Example, If I have a Column (Name) in a table, then I want it to accept only alphabets from A to Z, not Number or Numeric Value, varchar, char etc.
the data type is not the place to enforce your data integrity. it's either chars or numbers, and numbers can be chars. If you really need to enforce it at the db level vs in code (eg php) then you must do a stored procedure
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.
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)
When I add a number beginning with 0 into my MySQL database, it automatically gets converted to a single digit. These are mobile numbers, so I need to keep it starting with 0.
Store phone numbers as strings, not integers. (related: Common MySQL fields and their appropriate data types )
Try storing the numbers as varchars instead. When you retreive them from the database you could cast them using (int) if needed.
I have a column on a mysql table that stores mostly numeric values, but sometimes strings. It's defined as VARCHAR(20). There is an index on this column for the first four characters.
ADD INDEX `refNumber` USING BTREE(`refNumber`(4));
Since the field is mostly numeric, it is useful for the user to be able to query for values that fall within an numeric range (e.g., 100 to 2000). If I use a numeric comparison, this index is not used.
WHERE refNumber BETWEEN 100 AND 2000
If I use a string comparison, I get some values I don't want (e.g., 10000 comes back when querying for a range of 100 to 2000).
WHERE refNumber BETWEEN '100' AND '2000'
Is there a good solution to this?
Note: there are some values that are recorded with zeros padded on the front like 0234, which should be returned when looking for values between 100 and 2000.
Three possibilities
1) Separate the numeric values into their own column.
2) If you MUST keep things as they are, decide on a maximum length for the numbers, zero- or blank-pad the numbers to that length.
3) I don't know if MySQL supports function-based indexes, but that might be an option. if so, write a function that returns the extracted numeric value and use that as the basis of the index.
You can try using the string comparison first, so the index is used, and still do the numeric comparison afterwards. It shouldn't slow things too much, since the second filter will only apply to a small subset of the rows.
WHERE refNumber BEETWEEN '100' AND '2000' AND CAST(refNumber as SIGNED INTEGER) BEETWEEN 100 AND 2000