when creating tables(and columns inside it) using MySQL gui clients there is a field called 'length' of a column. What exactly does it mean. Isn't range for a datatype (say)int fixed. Does length relate to the range of column value in anyway? Thanks.
Isn't range for a datatype (say)int fixed.
No - but MySQL has some predefined sizes for integers.
Does length relate to the range of column value in anyway
Yes, it sets a limit on the size of what you put in there - but don't assume its directly equivalent to the number of characters you key in (see previous link, also, this one on multibyte characters)
yes, indeed. E.g. a varchar(255) field can hold up to 255 characters.
see http://dev.mysql.com/doc/refman/5.0/en/data-types.html for all datatypes
Related
When defining a column in SQL Server we can do [Photo] VARBINARY(MAX), this automatically sets the length of the field to the maximum. In MySQL I've tried to do the same but it seems that that this should be done in another way. So, I've been looking for the equivalent of this in MySQL. I've tried googling by I keep coming up with the results defining the max in numeric value like 65535. Tried that, but the MySQL says it is too large for the field.
No in MySQL there's no such a const MAX which defines the maximum column length. Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 65,535. The effective maximum length of a VARCHAR is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used.
The equivalent to varbinary(max) would LONGBLOB in MySQL:
http://dev.mysql.com/doc/refman/5.5/en/blob.html
If you have a MySQL table with a very large number of rows that includes a variable length field that is often used in WHERE or ORDER BY clauses, and it is infrequent that INSERTS or UPDATES are made, then it would be a good candidate for using an index on the field.
However, from what I could find on the topic, it seems MySQL doesn't handle variable length fields very quickly (compared to fixed length fields) when you index them in this manner. So, I was wondering if it would make sense to left pad the column's rows with empty strings to force all of them to some fixed maximum length. Would this make any sense at all? Or am I just over thinking this?
After consulting the manual some more, I realize this is a "feature" already baked into MySQL:
The length of a CHAR column is fixed to the length that you declare
when you create the table. The length can be any value from 0 to 255.
When CHAR values are stored, they are right- padded with spaces to the
specified length. When CHAR values are retrieved, trailing spaces are
removed.
Searched the docs, but to no avail.
What is the maximum length for an enumeration value, i.e. the string literal?
The limit isn't on the length of the literal string, but rather on the table definition.
The MySQL documentation states that
Each table has an .frm file that contains the table definition. The server uses the following expression to check some of the table information stored in the file against upper limit of 64KB.
which is then followed by an ad-hoc equation expressing the approximate size of a table definition.
For a simple test, in a table with a couple fields already, I got my enum up to 63136 characters long, and the .frm was 71775 bytes big (slightly larger than 70KB), so the limit is approximate. At that point, MySQL complained #1117 - Too many columns, which is misleading to say the least.
Interestingly/oddly/worthwhile to note, the character set of the enum will change the maximum length. -- even if you're using normal characters which should only require 1 byte each.
An ENUM column can have a maximum of 65,535 distinct elements. (The practical limit is less than 3000.) A table can have no more than 255 unique element list definitions among its ENUM and SET columns considered as a group.
For years I have been under the assumption when I create a new column of type bigint(12) for a MySQL table that the field is limited to integers with up to 12 digits. However, I recently noticed that values up to 16 digits are able to be written into and selected out of a bigint(12) defined column without any warnings or issues.
Can someone please help me understand why this is the case and what that column definition actually means? Thanks in advance!
bigint(12) is not truncated at all. The 12 is used for display purposes.
Have a look at Numeric Types
Numeric Type Attributes
MySQL supports an extension for
optionally specifying the display
width of integer data types in
parentheses following the base keyword
for the type. For example, INT(4)
specifies an INT with a display width
of four digits. This optional display
width may be used by applications to
display integer values having a width
less than the width specified for the
column by left-padding them with
spaces. (That is, this width is
present in the metadata returned with
result sets. Whether it is used or not
is up to the application.)
The display width does not constrain the range of values that can be stored
in the column. Nor does it prevent
values wider than the column display
width from being displayed correctly.
read Numeric Type Attributes section from MySql documentation INT(4) specifies an INT with a display width of four digits
So I was creating a table for comments, and I was wondering. What would be a good type for comment details? I put longtext. Well then, why would people need varchar if longtext can handle it? Also, which type would I want for usernames?
What is the purpose of "primary" for index? What is the purpose of index?
Update:
Let's say a comment was actually a review.
It is true that TEXT can handle any input you'd place in VARCHAR or CHAR field. In fact TEXT could handle and data you might want to put in DECIMAL, INT, or almost any other type as well. Following this logic we might as well make every column a TEXT type.
But this would be a mistake. Why? Because using the appropriate column type for the expected input allows the database to better optimize queries, uses less disk space and makes the data model easier to understand and maintain.
In regards to the questions: a username column should use VARCHAR(20), since you would want and expect that most usernames are going to short, usually no more than 10 - 20 characters long. For a review column (like a movie review or book review) a TEXT type would be appropriate as reviews can span a single paragraph to several pages.
In regards to indexes, try this link:
http://20bits.com/articles/interview-questions-database-indexes/
That depends on what a "comment" is in your system. Typically VARCHAR is pretty standard for both comments and usernames. This limits you to about 255 characters, which is generally pretty acceptable. If you need more characters in your comments, you can bump it up to a text, which gives you a little over 65k chars.
For more information, see the String Types Reference.
TEXT NOT NULL. That gives sufficient room, has a 2 byte overhead, and generally presents no problems.
Regarding TEXT
On comparisons, TEXT is space extended
to fit the compared object, exactly
like CHAR and VARCHAR.
For indexes on BLOB and TEXT columns,
you must specify an index prefix
length. For CHAR and VARCHAR, a prefix
length is optional. See Section 7.4.2,
“Column Indexes”.
BLOB and TEXT columns cannot have
DEFAULT values.
If you use the BINARY attribute with a
TEXT data type, the column is assigned
the binary collation of the column
character set.
Regarding VARCHAR:
Values in VARCHAR columns are
variable-length strings. The length
can be specified as a value from 0 to
255 before MySQL 5.0.3, and 0 to
65,535 in 5.0.3 and later versions.
The effective maximum length of a
VARCHAR in MySQL 5.0.3 and later is
subject to the maximum row size
(65,535 bytes, which is shared among
all columns) and the character set
used.
More at: http://dev.mysql.com/doc/refman/5.0/en/blob.html
Have a look at this web page, it lists all the MySQL field types and describes what they are and how they're different from each other.