Herbert Senner wrote:

> one more comment from my side to Geoff's considerations.

Good points Herbert. Also on that other side I would add:

* complexity : the file-system based solution is more complex
to set-up (how much so depends on the requirements)

* adaptability : a database solution is more flexible in the
way you can re-arrange things as requirements change

* integrity : blobs are inside the database and part of the
transaction, files are not. Depending on how you use the
files this can be an issue for integrity and consistency.

Added to the issues of managing large numbers of files and
security that you mentioned, these add up to lots of good
reasons for wanting files inside the database.

The importance of each aspect is obviously implementation
dependent. There are ways to ameliorate some of the issues,
* database size issues can be managed through the use of
multiple databases
* client-centric issues can be managed by passing files
from the server - via blobs (F_BLOBLOAD udf or similar),
or via separate network pipes.
but these add to development complexity.

On a security note, it is relevant to remember that blob
storage is not secure storage. The blob access APIs are not
protected in the same way as normal row data, it is possible
to extract blob data directly, bypassing normal row access,
by "guessing" the blob-id (which is simply the relation-id
and a sequence number).


I hope Jason will forgive this not entirely on-topic thread.

--
Geoff Worboys
Telesis Computing Pty Ltd