This is another one of those topics where you have to be aware of the plusses and minuses of storing binaries inside the database, or outside with only a file path reference in the database.
Here are my 2 cents on this topic -
Advantages of putting binaries in the database -
1. Never have to worry about duplicate image filenames etc.
2. Never have to worry about access permissions.
3. Never have to worry about security outside of your ASP.NET app.
4. Easy porting because it's all in one place (the db).
5. Transactions dude ... :) that is a nice nice thing !!
Downsides of putting binaries in the database -
1. First of all consider the cost of serializing the document/image into the blob.
2. Second think about timeouts and broken streams when retreiving larger datas that aren't quite one shot.
3. Third, your larger files will go from d/b to web server as 4 kb chunks and each chunk will require handshaking - too much overhead - you decide.
4. Fourth, What really guarantees that you will never run across an image > 50KB or document > 1 MB
5. Fifth, Sql server is gonna break the image/document up so it fits inside it's small small pages, and obviously it'll have to peice it together in a select query.
If I had to, I'd say keep small binaries in the database, and large binaries outside.
And for all you non-believers, who insist that binaries in a database are *always* a bad idea, remember, sharepoint stores binaries in the db. Also, check this out (in short, terraserver.microsoft.com stored images in Sql Server - and that was a LOT of data).
IF you _HAD_ to store binaries in the database, what can you do to alleviate the bad effects (to some extent). Here is a short list -
1. Use DataReader with CommandBehavior.SequentialAccess - this way you read the big blob only if you have to.
2. Contrary to popular belief, command builder will simply ignore the binary columns - so don't count on that :-)
3. Split the table vertically using a one to one relationship, index the PK/FK, and store the binary column on a seperate tablespace on a seperate disk altogether.
4. Don't use binary columns in where clauses :-)
5. Don't use binary columns in FOR XML queries - except FOR XML EXPLICIT where you can specify the xmltext directive to put stuff in cdata.
6. Conserve Resources when writing large blobs to the database.
Anyone have anything else to add? :-)