Hi I have got a column in my database which is set to Int.
But my data always starts with a 0 so whenever I add a new record, it strips the 0 off and I don't want it to do that incase the first character has to be a 1 at some point.
How can I overcome this issue?
Is the best way to use VARCHAR any then validate using PHP?
Update
If I enter 02118272 it is saved to the database as 2118272.
The integer 7 is the same thing as the integer 000000000000000000000000007. They're both... ya know... seven. When stored in the database, it's actually stored as something like 000000000000000000000000007 but most MySQL clients won't bother to show all those zeros.
If it's important in your application to show these numbers using a certain number of digits, you can add back as many leading zeros as you want using the str_pad() function:
str_pad($your_string, 10, '0', STR_PAD_LEFT);
Here, 10 is the length you want the string to be, '0' is the character that will get added on in order to make it that length, and STR_PAD_LEFT says to add characters to the left-hand side of the string.
If, on the other hand, the number '007' is fundamentally different than the number '7', then you will have to use a VARCHAR() field to store it. Those are no longer integers; they're strings with very different meanings.
What you should be storing in your database is data. Formatting of that data is the responsibility of applications, not the database itself.
I would store it as an integer and, if you need that to 7 decimal places with leading zeros, the right place to do that is after extraction of the data to your application.
I think that you should use varchar type for that field. If you want to convert a variable to integer in php you can simply do this:
$var=preg_replace("/[^\d]/","",$var);
with this you delete all characters that aren't numbers and then you can put this value into the db preserving the initial 0.
Related
I want to show the following numbers with php, but output is strange:
echo 3333333333333333333333333333333; // -----------> 3.3333333333333E+30
echo 0.000025; // -----------> 2.5E-5
I havent asked it to convert. Why it does that? How should I force it to get/set the values exactly as I ask it? (p.s. I've heard of sprint_f or number_format functions, but I don't like them, because i have to know the formatting and length in advance.)
What is more, when I try to save large numbers in Database, there is saved a number: 2147483647 (i found that was the max. integer value). I changed the column type from int to varchar(100) but still same truncation happens.
Look at your precision setting in php.ini
http://php.net/manual/en/ini.core.php
It's the setting that says how PHP will output numbers
When you are using such extreme numbers (both negative or positive) the accuracy of the number system in php comes in to play.
Floating point is not accurate for numbers like that, I would suggest using one of the ones listed here
http://php.net/manual/en/refs.math.php
bc is designed for decimals
Well, I will answer my own topic.
1) The first problem is that PHP truncates LARGE and smallest values... However, I solved that casting values to strings (with double quotes).
2) The second problem was a bit strange...
When I first created that MySQL, I made that column as INT(11) and then changed column to Varchar(100) (exactly as all my other columns were Varchar(100) and they could save that value well).
However, that column was truncating values again. Then I recreated the table, but changed the COLUMN name and then IT WORKED WELL! I think, MySQL cached the column type (or surely something like that happened) !
Data type in php (that I should set for a column in phpmyadmin) for entering both character and decimal numbers. Ex. 0.09 or n.a. or 100 (1) all such things can be feed in to the column.
A VARCHAR type can be used. This will store a string allowing your characters or decimals. Be sure to set an appropriate length - not too short or the data will be truncated.
If you find yourself storing lots of different types of data in a single field, then it may suggest you could use a better table/db design.
I would personally store that data in two different fields:
one INT for whole numbers
and one DEC(m,n) for decimal numbers * m is number of all digits and n is number of digits behind the decimal separator.
For example: DEC(5,2) data for this would be 123.45
If you need it to be in one field use VARCHAR but this is not my recommend, since it is not good to store integers in varchar type field.
Though a varchar is not recommended, but if you are using a varchar make sure you typecast the variable in your code while fetching.
I am in need of storing a score in a mysql field but this score could be a time,integer or float. My first way of doing this was to identify the score type and then enter it into one of three fields but if the need arises to add a new score type I dont want to have to continually add a field to the database. I remember somewhere down the line someone told me that if you store somethign as a varchar then is wont be able to be read as an integer or float or even date. My question is, can I store all three of those as one specific type but read it any way I need when taking it from the database and using it in my php code?
In my opinion you could model the field as FLOAT except if you absolutely need to know about the type of variable stored. Time can be converted to an integer value by converting to timestamp. Integers are a subset of the real (floating point) numbers set actually so I guess that way you have everything covered. Floating point arithmetic can cause some issues with precision and equality testing though so be careful!
You can use CAST and CONVERT functions to convert the string datatype into another MySQL datatype such as INT, FLOAT, DECIMAL, DATE, DATETIME etc.
There are a few issues. How do you know what datatype is stored in a row? MySQL does have RegExp support but I do not recommend using it in your WHERE clauses. Store the datatype in another column.
Also, using cast functions in the where clause of your query will make them run slow. If you need to search upon/sort by the data you should use proper datatypes. Perhaps you should add one column for each datatype; and for each row, populate only the corresponding column.
mysql will happily convert text to numbers of the appropriate type if you perform a mathematical operation on it. However, it will also convert non-numeric text to zero and perform the same operation on it, so you need to check that you're only pulling fields of the appropriate type beforehand.
This forum post shows how to add a regular expression condition to your query to ensure that you're only pulling fields with numeric data in them. However, I think it's probably wiser to use a separate column to indicate what type of score each record is, and use that to retrieve the appropriate ones.
I don't know how to convert text to a date (putting it through date() doesn't work). However, note that the mysql date format (2012-05-08 11:20:23) has the date elements in order of descending significance. If you just want to find the highest / lowest date, or sort by date, treating them as strings will work fine.
I have a table with a current structure as follows:
Currently this is populated as follows:
The data stored for product value is a decimal value
and the end digits are cut off once it is inserted into the database.
I have tried changing the table structure as follows:
However this only leads to the following:
As you can see all values have a .00 appended if none exists, however I want to
store all these values with no decimal places. Except the product value.
How can I do this?
The trouble is you are converting a decimal (float / double) to an integer, so the value is simply truncated (decimal values are chopped off).
If you really don't want to use floats (decimal values) in the database you can use this hack work around will work:
Multiply the number by 100 before inserting it, and then be sure to divide it by 100 when you use the data. This will allow you to maintain 2 decimal points while using integer storage.
Thus, 2.4 would be stored as 240, 53 would be 5300, 20.74 becomes 2074 etc...
I want to note that this is not an ideal solution, but rather a hack.
I highly recommend what the other users suggested in the comments: storing the decimal value (as you have) and formatting it when presenting it.
--- In addition ---
Your real problem appears to be with the way the database is setup.
Each of those values should have their own field since they will be repeated for each product.
Can we declare a variable with fixed length in PHP?
I'm not asking about trimming or by putting condition do substring.
Can we declare variable just like database char(10).
The reason I'm asking am doing an export process, PHP export data to DB.
In DB I have a field with size 100, and I'm passing a field with length 25, using PHP.
When I look in DB, it's showing some extra space for that field.
Maybe it's your database that is the problem.
The CHAR datatype will always fill up the remaining unused characters when storing data. If you have CHAR(3) and pass 'hi', it will store it as 'hi '. This is true for a lot of relational database engines (MySQL, Postgres, SQLite, etc.).
This is why some database engines also have the VARCHAR datatype (which is variable, like the name says). This one doesn't pad the content with spaces if the data stored in isn't long enough.
In most cases, you are looking for the VARCHAR datatype. CHAR is mostly useful when you store codes, etc. that always have the same length (e.g.: a CHAR(3) field for storing codes like ADD, DEL, CHG, FIX, etc.).
No, a string in PHP is always variable length. You could trim the string to see if extra space is still passed to your DB.
Nope. PHP has no provision to limit string size.
You could simulate something in an object using setter and getter variables, though, throwing an error (or cutting off the data) if the incoming value is larger than allowed.
No, but I really don't think you're having a problem with php. I think you should check your DB2 configuration, perhaps it automatically completes strings with spaces... How much spaces are added? Are they added before? After?
As others have said: No.
I don't understand how it would help anyway. I'm not familiar with DB2 but it sounds like if you have extra spaces, they are either coming in the variable (and thus it should be trimmed) or DB2 does space padding to make the value have 100 characters. If your input is only 25 characters long then if it is doing space padding, it seems it would do it anyway.
If you want to store variable length strings in DB2 then go with VARCHAR, if you always want the same length for each string in the column, define the exact length using CHAR (for postal codes, for instance).
Details on character strings is available here: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0008470.html with a good summary:
Fixed-length character string (CHAR)
All values in a fixed-length string column have the same length, which is determined by the length attribute of the column. The length attribute must be between 1 and 254, inclusive.
Varying-length character strings
There are two types of varying-length character strings:
A VARCHAR value can be up to 32,672 bytes long.
A CLOB (character large object) value can be up to 2 gigabytes minus 1 byte (2,147,483,647 bytes) long.
Of course it then gets more detailed, depending on what sort of encoding you're using, etc... ( like UTF-16 or UTF-32 )