BLOB can hold any binary data, but it's not typically advisable to store that data in a database. There is no reason, for example, to store images in a database, but for some reason a lot of people like to do that. Store your binary data in directories and use the database to store the path(s) (pointers, references, whatever you want to call them) to that data. Your database will thank you.
Interestingly, I had a debate with a person about this a few months ago. They claimed that when sites get
big, there is actually a lot of benefit to be had from storing large binary BLOBs in the database. Here's an excerpt from that conversation:
Attachments need to be able to be stored on the filesystem or in the database. Most people don't know it, but having your attachments in the database is HIGHLY preferable in most scaling hosting situations, for many reasons.
The first major reason is cluster filesystems. If you have 10 webservers accessing a GFS share on an iSCSI SAN via gigabit LAN, and they are all running DLM (also via gigabit LAN), you want to keep the number of files down(or at least not intentionally make hundreds of thousands of them), and DLM introduces overhead to the network/systems for every webserver in the cluster. Efficiency isn't always the goal though. In the case of my guild's forum, it has a 20GB attachment table and the whole cluster just performs much better when it's in the database, even if the database server is spending more cycles, storage(indexes) and memory/caching to retrieve that data than all of the webservers would via GFS/DLM. It usually takes me about 8 webservers to overwhelm 1 database server, so I'm interested in being able to shift that load to the database servers. On the topic of load, I've had 5,000 people viewing a thread on a forum that typically has 50-100MB of attachments per page and the load from the attachment table is still literally negligible, aside from network bandwidth - but at least it's coming from 1 server, not flying all over the place with DLM and the SAN.
Database servers typically not only have local storage versus network storage on a webserver cluster, but it's usually extremely fast local storage. This is great for situations such as when 5,000 people are hitting an attachment thread. It's also easy to load balance multiple network adapters on the database server via host entries on the webservers, whereas it's quite a bit more complicated(and expensive) to make a multipath SAN fabric or expand beyond gigabit ethernet to 10GbE or FC/infiniband, and you have to expand your DLM network to a faster fabric along with it.
So it's something we have in the back of our minds for the future.