>>>>>>I had read somewhere recently that shrinkfile was a bad idea. Have you had any problems with it?
>>>>>
>>>>>Not at all
>>>>
>>>>Here's one of the articles: http://www.sqlservercentral.com/articles/SHRINKFILE/71414/ not sure if you need to join to read it, but joining is free.
>>>>
>>>>A quote from the article:
>>>>
>>>>"In the SHRINKFILE command, SQL Server isn't especially careful about where it puts the pages being moved from the end of the file to open pages towards the beginning of the file. This causes two problems:
>>>>
>>>>the data becomes fragmented, potentially up to 100% fragmentation, this is a performance killer for your database;
>>>>the operation is slow - all pointers to / from the page / rows being moved have to be fixed up, and the SHRINKFILE operation is single-threaded, so it can be really slow (the single-threaded nature of SHRINKFILE is not going to change any time soon)."
>>>
>>>I don't know if I would go as far as calling fragmentation a performance killer. Obviously it is not good for performance but it happens in every database. I wouldn't expect it to be noticeable unless the database is large.
>>
>>and updated a lot..
>
>I'm not sure what constitutes a large database these days but I was a bit concerned with using the command when a client's SQL Server Express hit 10GB with about a year and a half worth of data. They probably enter a few hundred transactions a day and load in PDFs too. But I am definitely not an expert in this area so I am trying to understand the pros and cons.

If they are putting PDFs into the database they might as well purchase a standard edition of SQL Server.

Personally I never include files in a database. I either keep links to files in the file system or use the FileStream or FileTable capabilities in SQL Server (which stores files external to the database as well).