We are currently developing a custom document versioning application for a large government contractor. When we received the initial functional requirements, in early 2008, SQL Server 2008 was still in its CTP form (Community Technology Preview). It became clear that the new Filestream functionality of SQL Server 2008 was a perfect fit for this project.
Documents and file (unstructured data or BLOB) storage, in general database terms, can be complicated. Traditional BLOB storage can be cumbersome, as the file data is read into the SQL Server buffer pool and then out to the client application. The available memory of the server is unneccesarily filled with this BLOB data and can bog down performance. This is not an issue for smaller files, and may actually provide a better storage solution. Also, it can be simpler to maintain security for these BLOBs by storing the actual data in the database, with only one login to manage. However, large files in the database can cause the data files to become fragmented, and this is better managed by a file system than the database. Depending on the storage needs, costs can skyrocket. And multiple technologies adds a layer of complexity.
These are just some of the many things to consider - pro or con - when choosing a means of storing BLOBs. The SQL Server 2008 Filestream feature allows structured data to be stored directly in the database, while associated unstructured data can be stored in the Windows NTFS file system. By utilizing SQL Server's high-performance APIs to stream this BLOB data, you do not pay any performance penalties. Filestream also maintains the transactional consistency of all the data at all times, not requiring any custom logic.
For these reasons, and many others, we began developing this solution with SQL Server 2008 right off the bat, and it paid off immediately. It is for both the logical benefits and our positive experience that when considering development of a solution that requires extensive BLOB storage, we highly recommend SQL Server 2008.