For a quick background, I have an app that I currently support which runs on Oracle 10.2 with dedicated DBAs. In the past when I’ve wanted to create a table that would store binary data (BLOB in their world – this could be PDFs, DOCX, etc.), the DBAs would always “partition” the data storage of that column/table (not sure which) to a separate physical area on disk. Their reasoning behind this was it helped ensure performance wasn’t impacted by having a large number of binary files stored in the same file as the rest of the data where lookups occurred.
My question is whether or not I should do something similar to this for SQL Server (2012, though I doubt the version matters)? If so, how might I go about it and what is the proper terminology for doing so?
You could create a separate filegroup whose file(s) are on a different volume, and then explicitly create the tables that store your LOB data on that filegroup. Filegroup designation is part of the CREATE TABLE and CREATE INDEX statements, the default being the PRIMARY filegroup.
You also have different choices for storing files in SQL Server, in 2008+ you can use FILESTREAM (see also here) and in 2012 you can use FILETABLE. However in most cases I’ve had a hard time justifying storing the file in the database; it’s often less problematic to store the file on the file system and a pointer in the database.
And you can read my dated and long-winded opinions in this FAQ article I wrote 12 years ago.
Keeping in mind that some technology has changed (obviously FILESTREAM and FILETABLE weren’t available then), some of the points there remain relevant…
And finally, some advice on MSDN about file / filegroup handling that might be useful reading.