ТО Cristo :
Мы реализовывали вариант через СП, уже писал об этом, но если кратко:
- вероятность потери целостности минимальная...
- улучшенная безопасность
- компонент на СП является связующим звеном между БД и файл-сервером и для любого клиента является одной и единственной точкой работы с данными.
- улучшенная масштабируемость, причем явная. Каждый СП может содержать свой репозиторий, в принципе, в зависимости от задачи можно усложнять компоненту в плане масштабирования и надежности вплоть до децентрализованного репозитория хранения файлов.
- упрощение жизни в плане хотелок работы с системой. Хотите щас использовать СУБД для хранения файлов - пожайлуста, хотите завтра файл-сервер использовать - нет проблем. Клиент при этом не переписывается, все изменения на уровне СП. Хотите свою схему... тоже не проблема.

Так что вот вариант.

С хранением файлов в СУБД есть ряд проблем, для нас основной стала масштабируемость и надежность системы доступа к хранилищу документов. В БД на мой взгляд не очень эффективно хранить документы, к которым идет частый доступ. Сильно вырастает траффик - СУБД становиться быстро узким местом всей системы. Приходиться решать вопросы закупки мощных железок и хорошего сетевого оборудования.

Вопрос можно решить иначе, на узловых участках ставить СП (например, каждой рабочей группе, отделу, управлению... ). Эти участки легко определяются после анализа трафика... На каждым СП храниться локальный репозиторий, все СП объединяются в кластер, в БД храняться карточки документов и описание такого вот распределенного репозитория. Для обеспечения должной надежности, можно реализовать схему некоторой избыточности данных, либо бэкапить. На каждом узле СП храняться "свои" документы и наиболее часто используемые. Так как простой проверкой выяснили, что у нас "наиболее используемые" и "свои" совпадали... Поэтому даже и не напрягались с кэшированием и синхронизацией, хотя и это сделать довольно просто.

Конечно, в простейшем случае - в качестве репозитория используется 1 файл-сервер с нормальным рейдом.

Но вышеописанная схема позволяет "работать" системе даже при выходе из строя ряда серверных. При пожарах, заливах, перегревах.... Тоже думаю неплохо.

А ведь все начиналось с нескольких компонент на СП и на 1 физическом сервере с ASA. Клиент не переписывался... Все проблемы решались на уровне конфигурирования серверов, БД и компонент на СП.

Вот так примерно...