I would agree, when it would be possible to select with attachments to write to the file vault - like another idea for source said. Imagine the rich text field contents gets written to a file vault when someone tries to open the document than this information has to be retrieved from the file vault. On the other side you can limit the attachment size and force people to put bigger attachments to a project in PTC Source - this project than can be on a file vault. But I understand, when you say documents are old, than you could argue who bring everthing concerning attachments e.g. images and attached documents to a file vault. But then may be, you shoul have a policy or option to select which file vault to use, which could also be configurable per project.
Putting files into Source Integrity is just a workaround - you would force people to switch methods how they store attachments depending on the files' size. Also, when looking the files up, you would always have to check two places for the content (attachments and linked source project). Where the attachments are stored should be transparent to the user, as it is not of the users concern. If you want to store unstructured data, like protocols, logs, drawings, sketches and other document together with requirements and tests, because they give reasoning, help in elicitation etc, I think this is a valid use case. This data, on the other hand, as it is just a chunk of data or blob to Integrity, shouldn't be stored in database, that's not what databases are made for, the content isn't even indexed.
This data belongs to a file store, this will reduce of db storage needed (far more expensive than simple file storage), an keep db backup sizes small. And with fiel vaults for source, the infrastructure is already there.
