My colleague setup a MySql database. For two fields where one can enter longer text he used database type BLOB. The problem now is when someone is entering German "Umlaute(ä,ö,ü)". These are not shown properly when I retrieve it later from the database to show it to the user. Instead they are shown as weird signs. I mean, in my java code these Blob objects are simple Strings. What can I do to show these special character (Umlaute) properly again?
Short answer: you need to change the column type to TEXT.
The first B in BLOB stands for binary. With such column type you're telling MySQL explicitly that you don't want its contents to be handled as text. For that reason, you'd need to ask everyone who enters data what encoding they are using and then make a conversion from that encoding to your application's encoding. Of course, you also don't have any way to control how others are writing and reading data so you could eventually find different encodings in different rows.
BTW, both BLOB and TEXT have a maximum length of 65,535 (216 − 1) (bytes in the case of BLOB, characters in the case of TEXT), the same as VARCHAR. If you really want large text that don't fit in VARCHAR you may want to consider larger types like MEDIUMTEXT or LONGTEXT.
Related
I want to encrypt text using AES in mysql, but I have a small problem, because you need to use varbinary to store these.
Some of my datatypes are varchar and yes I can probably work out the length of my varbinary for these. However for my address fields I use the TEXT datatype, as we have Chinese addresses stored and these can be very long. I use the TEXT datatype because you do not need to specify a length in mysql.
The problem is that with varbinary you need to specify a length, and I don't really know the length because the addresses can be of any length.
Is there some kind of binary datatype I can use for AES where I don't have to specify the length of the data?
As per comments - you require BLOB data type, which is short for Binary Large Object (thanks Maarten Bodewes for clarification).
A BLOB data type won't store character set with the information and is equivalent to TEXT type, without a charset. As mentioned in the comments, there are other types such as MEDIUMBLOB, TINYBLOB, LARGEBLOB, they are all covered on MySQL's manual page.
I am building a small blog system for adding news to my website and I want to know what is the most useful type to save the news in the database with the html format and get it from the database with its plain text format to show in the browser??
It'll depend on how large the strings your storing are but most likely you'll want to go with the Text datatype (nonbinary version of Blob).
The general rule of thumb is to use VARCHAR up until 255 characters, then use Text. Blob and Text both allow you to store huge string values without removing line endings.
For your use TinyText will most likely suffice.
You can read more information on them here:
http://dev.mysql.com/doc/refman/5.7/en/blob.html
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).
What are the tradeoffs in choosing a TEXT datatype as compared to a BLOB or BINARY datatype? I don't intend to index on the column or use it in a WHERE clause, it's just data in the database, that happens to be textual. If there's a performance or storage advantage to my choice of datatype though, that would be good to know... Thanks!
Short answer: If it's text, use the TEXT datatype.
Long answer: TEXT columns are treated as text, i.e. they have an assigned character set. If you do comparisons between TEXT values, it will use your character set's collation rather than just comparing their numeric values. BLOB columns, on the other hand, are just arrays of bytes; they have no defined character set. If you're storing unicode (or other 'wide character' encodings), you will definitely want to use TEXT, since your data will be basically opaque to the db unless you do.
They can both store the same amount of data (depending on which of the subtypes you're using, of course), but you might see a small performance gain in using BLOB for binary data since there won't be any text-related processing going on with it.
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.