I have an old database table with column, which type is BIGINT. There's a lot of stored procedures and views that use that table and that column.
For some reason I need to change the type of that column to NUMERIC(38,0).
Is it safe to do it? Should I cast in any stored procedure and view existing BIGINT to NUMERIC(38,0)?
According to me numeric data type is identical with decimal which represents a fixed precision number, which will scale numeric data from -10^38 +1 through 10^38 –1
I don't think that the number types you mention are using fixed precision number and therefore BIGINT is probably the most efficient way to store the number especially if you want to perform some computation in your application.
I don't see really any use for computation with those number and therefore you may even use a string of appropriate length which requires more space in the database but you may be able to allow grouping characters in the numbers.
using BIGINT datatype instead of string you can create efficient indexes.
As you write you're already using numeric datatype and therefore if you upgrade to SQL 2008R2 / 2012 you should consider switching to BIGINT as you don't need fraction in your number. The BIGINT data type is intended for use when integer values might exceed the range that is supported by the int data type.
EDIT:
You can change the data type from BIGINT to NUMERIC(38,0) but be ensure that a Arthimetic overflow error shouldn't occur while converting.
Yes, it is.
According to this table on MSDN an numeric(38,0) has an higher capacity than a bigint.
I calculated the maximum values based on the numbers in the matrix:
9223372036854775808 (bigint, 2^63-1, 8 bytes)
1000000000000000000000000000000000000000 (numeric(38,0), 10^38–1, 17 bytes)
Related
I do realize that it is better for a column to be an Integer if one has to perform mathematical calculations on it.
I probably have to perform mathematical calculations on the "year" column but minimally. So would it be better to store it as a String or Integer?
Thanks.
Save it as an integer.
While there may be some application where you are reading and serving this data so frequently that the int->string conversion is a problem... that is going to be an edge case.
On the other side
Integers provide smaller options than strings in data storage (such as TINYINT)
You avoid conversions due to math
It's going to confuse/annoy/frustrate all the developers that come after you when they query a data type that is naturally a number and get a string.
If you are not expecting your YEAR variable to ever contain non-digit values then yes you should store it as a number.
I would not store it as INT since I doubt year will reach the limit that INT has to offer. I would save it as SMALLINT or even TINYINT either should be unsigned.
SMALLINT UNSIGNED gives you max value of 65535, unless you are storing years that exceed the year 65535 this should suffice.
You could go crazy and save it as a YEAR!
This limits you to 1901-2155.
If this is too restrictive, I prefer a CHAR(4) to an INT; MySQL DATETIME comparisons are done in a string like manner..
You can do things like
WHERE year < CURDATE()
without worries then.
I use the Navicat MySQL GUI and have noticed there are Length and Decimal settings for all columns:
I understand the how the length and decimals settings work for float and decimal data types, but do they matter for other column types such as int and datetime?
MySQL doesn't use the term "Decimals", so that must be a term decided upon in the GUI tool you're using when defining DECIMAL or FLOAT types. For authoritative information, consult the GUI tool's documentation on how these settings affect types they wouldn't normally seem to apply to.
Searching around Navicat's documentation turns up little of any use on how it expects "Length" and "Decimals" to apply to integer and date types:
se the Length edit box to define the length of the field and use Decimals edit box to define the number of digits after the decimal point (the scale) for Floating Point data type.
...so not really helpful.
MySQL has a few options for storage length of integer types (which limit the maximum size of the integer that the column can hold), but those limits are specified by the name of the data type rather than a numeric length specified in the column definition.
This table of INT types explains the numeric ranges possible for each named type.
MySQL also offers an option on the integer types in the form of a display length like INT(11) which affects the displayed value rather than the stored value when using the ZEROFILL option.. Your GUI editor appears to map its "Length" option to the integer zerofill attribute.
See also: What is the benefit of ZEROFILL in MySQL?
How to find out, absent good documentation:
However, when working with a GUI client and not understanding what it is doing under the hood, the best advice I can offer would be to try out different settings and then examine the output of SHOW CREATE TABLE <tablename> to see what DDL statement the GUI ultimately constructed and sent to the RDMBS.
Syntax reference: SHOW CREATE TABLE
For datetime, it specifies the precision, and is a number up to 6. 3 will give you milliseconds and 6 will give you microseconds (millionth of a second). The length of an INT changes how the value is displayed, but it will still store the same value.
Besides using MySQL's DESCRIBE syntax and parsing the Type column, is there any way to programmatically determine what's the largest integer that can be stored in a given INT column and its varieties? (e.g. TINYINT, MEDIUMINT, etc.) I'd simply store a hard-coded table, except that my columns use custom lengths like TINYINT(2) and MEDIUMINT(5).
I ask because I'm thinking of writing a cron job to warn me when my various auto-incrementing integer-based ID columns approach their maximum values, so I can reduce the risk of integer overruns.
Edit
I see this was kind of a dumb question. As was pointed out to me, the custom lengths don't affect the maximum integer values that those columns can store. So if I wanted to write the script, I can hard-code the maximum integer sizes given in the MySQL manual. As to whether this script is the best way to handle things, that's debatable.
The custom lengths DO NOT affect the max value, in the case of INTs they are merely a hint for visually outputting/displaying the value AND are ONLY used when autofill leading zeroes is being used.
Please see: https://stackoverflow.com/a/6817537/330315 and here: https://stackoverflow.com/a/5634151/330315 and here: https://stackoverflow.com/a/4432037/330315 and here: https://stackoverflow.com/a/7048597/330315 (tnx to a_horse_with_no_name for once giving me these links.)
I'm using phpMyAdmin to create my table structures.
I can read from the documentation pages on MySQL about size limits for Integer Types:
MySQL Integer Types Reference
So here is where I'm getting a little confused with creating a column.
I want to create a column in the table: tbl_note_categories called notescounter
I don't foresee myself creating thousands of noteids in the tbl_notes with any specific categoryid. But I do believe I'd create hundreds of notes to each categoryid.
I'm at that point of choosing between: tinyint, smallint, mediumint.
According the documentation link above, I'm guessing smallint is my best choice.
So here's my confusion. PhpMyAdmin asks for a Length/Values parameter to be specified.
I'm going to make sure this new column (notescounter) is unsigned, giving me up to 65536.
Does that mean I need the Length/Values to be (5)?
I'm guessing Length is character length, but I'm not sure. (comparing to varchar)
No, this is a common misconception about MySQL. In fact, the "length" has no effect on the size of an integer or the range of values it can store.
TINYINT is always 8 bits and can store 28 distinct values.
SMALLINT is always 16 bits and can store 216 distinct values.
INT is always 32 bits and can store 232 distinct values.
BIGINT is always 64 bits and can store 264 distinct values.
There's also a MEDIUMINT, but the engineers who work on MySQL tell me MEDIUMINT always gets promoted to a 32-bit INT internally, so there's actually no benefit to using MEDIUMINT.
The length is only for display, and this only matters if you use the ZEROFILL option.
See an example in my answer to What is the difference (when being applied to my code) between INT(10) and INT(12)?
Yes, you want to specify a length of 5.
In MySQL, the "length" attribute on the integer types is optional. It's a MySQL extension which is non-standard).
When it is omitted from the column declaration, MySQL provides a default value. For a SMALLINT UNSIGNED, the default value is 5.
This value does NOT have any impact on the range of values that can be stored for an integer type. It specifies a "display length", which is returned in resultset metadata, which a client can choose to use or ignore.
http://dev.mysql.com/doc/refman/5.5/en/numeric-type-attributes.html
I created a table with column id as int data type. However, I realized that int type may not be able to hold some of the values I might put in the table. I wish to find out, if I define the column as bigint, does it take up "space" or does it use space on the database EVEN before I put a value in the column? I am using sql server 2008 R2. Thank you.
int always uses 4 bytes, bigint always uses 8 bytes. The actual value stored does not affect the size of the field.
Every time you enter any number, even 1, it will use the full 8 bytes. So the extra storage overhead is 4bytes * number of rows. If you are worried that you numbers will grow higher than 2,147,483,647, then you should use bigint.