When choosing "TEXT" as a type for a field in SQL, what should the length/values be? I have always skipped that field but just thought it might be an unsafe thing...
Am I right or do i need to set it to a certain number?
TEXT columns can have arbitrary length (for practical purposes, the length of a TEXT field is limited by available memory and buffers).
There is nothing inherently "unsafe" about TEXT columns. There are however a couple of caveats to be aware of, like MySQL only using the first 1024 bytes for sorting.
You can read more about all this on the the official MySQL documentation
There is no problem leaving the length blank as TEXT is variable length only taking up as much space as needed. See http://dev.mysql.com/doc/refman/5.0/en/blob.html
Related
When we creating database for our application, We limited lengths of database columns.
example -
String (200)
int (5)
etc
Is there any effect on Speed or some effect?
First of all, one does not limit the length of a "database". Instead, one does limit the size of columns of tables in a database.
Why do we do this, you ask?
We don't want to waste any space for data that's never going to use it (that's what the varchar, varbinary and the like are for).
It's a best practice because it forces you to think of your data structure BEFORE you actually use it.
The less data there is the faster the processing of the application (that's a tautology).
It makes it easier to validate your data if you know exactely how much space it is allowed to take.
Full text indexes gain greatly when limited in size
One reason I can think of is, When you didn't specify the length of a column data type, the MYsql engine would assume a default length value that may be a lot larger of the length of the actual data that would be stored in that column. So it is always a best practice never to ignore the length property of a column.
Limiting the length of database fields ensures validation of data, you won't get any unexpected data of a length other than what has been specified. Also certain fields cannot be indexed such as LONG so choose appropriately and wisely. With regard to performance the effect is negligible. You need to also think about the data itself, for example storing data in a unicode encoding such as UTF-8 may increase the storage requirements.
I can't help but believe this topic has been written about over and over again but I'm having trouble finding any good, solid information.
What data type should I use to store 200 to 400 words of text? What about longer articles that could approach two or three thousand words?
What options should affect my decision? I don't plan to search this data but I can't completely rule out the possibility that I may want to do that later.
Unfortunately my background is MS Access where the only option for this was a memo field. It doesn't appear to be quite so simple with MySQL.
If you're using MySQL 5.0.3 or later, go VARCHAR. It can hold 65k bytes. As long as you have only 1 long VARCHAR per row, you should be fine.
Otherwise go with text.
From the mysql manual:
BLOB and TEXT differ from VARBINARY
and VARCHAR in the following ways:
There is no trailing-space removal for
BLOB and TEXT columns when values are
stored or retrieved. Before MySQL
5.0.3, this differs from VARBINARY and VARCHAR, for which trailing spaces are
removed when values are stored.
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.5.1,
“Column Indexes”.
BLOB and TEXT columns cannot have
DEFAULT values.
Also nice to know (from the manual):
Instances of BLOB or TEXT columns in
the result of a query that is
processed using a temporary table
causes the server to use a table on
disk rather than in memory because the
MEMORY storage engine does not support
those data types
which you really should take into account when formulating queries which use TEXT.
A TEXT field should be big enough to store most articles. Seems to be about equivalent to Access's Memo type. It can hold up to 65535 chars, which would be somewhere around...i dunno...10-12,000 words, on average?
The TEXT data type is a safe bet for your situation, VARCHARs are usually used when they need to be indexed or there is a well-defined value to be stored (IP address, zip code, etc).
I have a table with a field that needs to store 512 characters. My question is this: can you limit the length of a TEXT field (VARCHAR stops at 255 - I can't use it) to 512 characters? If I do that, will MySQL run through the table quicker due to the fixed data length, or does it act a bit like VARCHAR in that the length can vary?
I don't have a table (at all) yet, but I'm very conscious about speed and size for the future. I found this article: link text incredibly useful - maybe you will to!
Thanks a lot,
James
Update your mysql server. Since 5.0.3 you can store up to 65535 bytes in VARCHAR.
You don't really say how you are using the table, so I'll just throw this in. One option is to separate out the text field into another table and just have a reference to it in your original table.
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.
When I have a text field, I generally store it as varchar. But then I encounter the issue of how do I know the limit I should place? Estimating how much text a user will type seems very imprecise.
As varchar uses as much space as needed, is it better to set the limit to far greater than you estimate?
Is there any disadvantage to using the various Text datatypes? Can it be searched using the "LIKE" operator and wildcards?
I think there could be cases where it's better to shrink the value of varchar. But in many cases it's fine to use 255 as it's limit.
Varchar can be searched with LIKE and wildchards.
If the user is likely to type more than 255 characters (the usual limit for a VARCHAR) then you need TEXT, but it can be indexed. MySQL has a FULLTEXT index for TEXT columns, which works reasonably well, but wouldnt be as quick as a CHAR or VARCHAR column.
Why not try a test out on your local machine with some dummy data to see how the performance compares, and if you can do the queries you would like quickly enough?