In the next week or so I’ll be upgrading the SQL 2005 server that has the SQLSaturday database and I’m looking forward to giving the filestream a workout. For those of you new to the issue for years we’ve had the choice of either storing files in the file system and a pointer (filename) in the database, or storing the actual file in the database. The generally accepted decision point was to store in the db if under 1 meg, otherwise in the filesystem. Of course, it’s all one or the the other per column, so you have to decide in the beginning. It’s always been hotly debated, but I’ve been in favor of storing in the db because:

• I can back them up with the db
• I can apply SQL security to them
• They are part of transactions
• Easy to replicate to other servers

But I also get that that doesn’t fit for all scenarios. Filestreams are new in SQL 2008 and are an attribute of varbinary(max) columns that let you store the file in the file system, but it looks like it’s stored in the table – an interesting hybrid. Right now we store the files associated with each SQLSaturday presentation as a single zip file in the db, so this will be a good exercise in migrating them out to disk as I convert that to filestream. Migration sucks no matter which way, but it strikes me as less painful for those that went with in the database rather than pointers – when I’m doing all the queries will still work and no changes required to procedures or code. I’ll have to write some code to test the streaming option to see if that would also be change free, but at rough glance it seemed like it was more than that. Good to experiment and learn some lessons on a real project, though admittedly a small one!