well, if you are in SQL2005, you cannot take advantage of the FileStream data type.
In that case, best practice depends on the size of the files you want to store. Moving gigs of data, regardless of where it's stored, takes time, so you want your application to have a strategy to minimize unnecessary downloads (ie download a whole table, but it shows one record at a time, and the user might scroll thru a dozen records)
As Far As I know, retrieving data from disk is is faster directly from the disk, without adding the overhead of SQL to retrieve the data; As a result, most times the database might have the path to the file and the filename, rather than the binary of the file itself.
If you could go to SQl2008 and use filestream, I believe there are articles stating that Filestream becomes more advantageous at a certain file size? 2meg? gotta google that)
I've placed tens of thousands of Icons into a database before,and the advantage there was they were small enough in size they didn't adversely affect performance too much; the other advantage was it was a little easier to find duplicate icons with the same name (i used grouping by file size + binary_checksum);
if the files are documents, you can use full text indexes on them and scan the file contents...but i think you can do that even if they are disk-based files as well? or is that only a third party control?
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!