Stick in a blob field.
Whether or not it's a good idea is a totally different issue.
In either case, typically, you'd want to keep various info about the picture... you want a unique ID (primary key), the human name of the picture, possibly the size, maybe a category title (or index/indices to a category table), who submitted it... (permissions?).
You also need the content of the picture somehow. You can either store the binary info in the database or store a path to it on the filesystem. It probably depends mostly upon how many files you have. If it's a whole lot, pesonally I'd store the binary info in the database. If it's a few (like less than 200), I'd probably store it using the filesystem. It probably also depends on the size of the files. Certain file systems deal with certain size files more efficiently. However, again the performance trade-off isn't necessarily noticeable unless you have extreme circumstances. If you have a lot of files, and they are all relatively small files, and your filesystem handles small files relatively inefficiently, you may consider storing the binary info in the database.
Some do, some don't.
Some people will tell you not to, some will tell you it's fine.
If it were me, I like to avoid hits to the filesystem, but even accessing the database is an implicit disk hit.
