On my website, an user can insert a hyperlink in a text input field. Then, this link (a string) is stored in my database.
On MySQL, the field that contains the hyperlink string is TEXT type, but I think its too long for this kind of information. Besides, VARCHAR(255) is too short sometimes.
What's the best type/length to store a hyperlink? It would be nice to know how long a link can be.
There is no limit to how long a hyperlink can be. Browsers limit the amount of data a GET request can send with a hyperlink, but there is no limit on how long the actual link itself can be.
A standard TEXT field will be fine for storing links (you won't suffer a performance hit for using that field as opposed to the VARCHAR(255) field type, nor will you use extra memory, so there's really no reason not to use it.)
See: What is the maximum length of a URL in different browsers?
You could use VARCHAR(2048) if you want a lower limit. There's nothing wrong with using TEXT in terms of space though. In both cases they only use as much space as the text plus a few bytes to represent the length. See Data Type Storage Requirements for details.
As for whether or not you should pick VARCHAR or TEXT see: MySQL: Large VARCHAR vs. TEXT?
HTTP does not specify any limit to the length of URLs. However, webservers and browsers may put a limit.
I guess some old IE versions have a limit of just around 250 characters.
Related
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.
it is my first experience with DB and therefore I'm kinda lost since I do not know much about it, so please go easy on me.
I am creating a table in MySQL where one of the columns will hold full path URLs to the images (one per line) like the following http://cdn.example.com/images/image1.png
My question is, what type should I give to this column, what MIME type, what Browser transformation and at last Transformation options?
So what I am trying to achieve is, when image is requested it should create the following
<img src="http://cdn.example.com/images/image1.png" width="150" Height="200" alt="Image Title">
I am also planning on creating another column for image width, image height and for alt.
can you please help me
Thanks in advance
Depends on the length of the URL you'll be holding but I'd use varchar(255) for the column type.
I've never had to worry about the MIME types. 99.999% of the time you will ignore them and just leave them empty.
Hope this helps you
if you are storing just the url and not the full tag varchar 255 should be enough. If you trim out the extra http:// , you save 7 characters
You can also use TEXT instead of varchar and not worry about the length restriction of varchar
remember to enforce length restriction at your application program level rather than at the db level .. e.g. dont allow URLs larger than 500 characters
VARCHAR access is faster than TEXT ... so depending on performance requirement you may have to make a trade-off here
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
I'm looking to store Tweets in mySQL. I would only need the message body and am looking for a recommendation as far as type and character length. Varchar or Text, if either of those.. how long? Tweets are limited to 140 characters, but I know there is a series of possible gotchas like re-tweets, #'s and links. Anybody went down this path? What worked for you?
I found this but this relates to the user name and not the message..
Twitter name length in DB
I think VARCHAR(255) is best for you. There isn't much reason to make a VARCHAR less than 255 since it is a variable length string it takes the same amount of space to store whether you limit it to 255 or 200. I don't think you have need for a TEXT data type. Side note, just in case: Watch out for injection attacks. Don't trust tweets, haha.
varchar can be used up to 255 i think that is more than enough buffer space for the gotchas.
even though i think you may be able to get by with varchar 200
It looks like it depends on the storage engine you are using. As VARCHAR fields, as opposed to TEXT fields, are stored in-row for the MyISAM storage engine. (I'm not sure but it seems there is not much difference when using innoDB)
So I would go with varchar.
I've been using varchar(300),but I've also noticed longer urls.
Use TEXT, it's enough for every URL.
Note that with long URLs, you won't be able to create an index that covers the whole URL. If you need a UNIQUE index, you should calculate the URL hash, store the hash separately and index the hash instead.
Technically HTTP does not put a limit on the max length of a URL. Read this SO post.
So varchar will not be of help, You'll have to use TEXT
As of now:
<< MySQL 5.0.3 use TEXT
or
>= MySQL 5.0.3 use VARCHAR(2083)
check this answer
As you can see here, browsers can handle different URL lengths (and very long). So you should consider using text as data type.