That makes sense - thanks.

>I've used in the lab at a previous job but left before implementation. One of the cool things is that if you delete the row in the table, SQL Server deletes the file. If you delete the file from some other way (Command prompt or Windows Explorer for example), SQL Server nulls the linked columns in the table.
>
>>We have an existing application that currently stores documents and other files as BLOBs directly in the SQL Server 2008 R2 database. It turns out the users are storing many more, and larger, documents than initially anticipated. To take the load off the database itself the plan is to store documents in a FileStream instead.
>>
>>Not having used FileStream before I thought I'd ask if anyone has any recommendations, any gotchas to look out for etc.
>>
>>There seems to be a basic introduction at https://technet.microsoft.com/en-us/library/bb933993%28v=sql.105%29.aspx . That has examples of how to get going with new tables etc.
>>
>>Since this is not setting up new tables, rather modifying an existing database I have more questions:
>>
>>- Can existing tables be ALTERed to support FileStream column(s)?
>>
>>- My first thought is we'll eventually want to migrate the existing BLOB data out to the FileStream and work just from that column. Otherwise we'd have to search both the existing and new columns for stored files and UNION the results. If that's the case, any tips about the migration process? My understanding is no users have huge amounts of data in BLOBs but it could be multiple gigabytes (order of magnitude)
>>
>>UPDATE: There seems to be useful information by Googling [sql server filestream best practices], I'll go through some of those results.