для пользователей требуется доп. разрешение на доступ к папке на сервере (одного доступа к БД будет уже недостаточно);
расшаривать каталоги на сервере ни один нормальный админ не даст. в некоторых случаях (например, сегментированная сеть с security-зонами) - это может быть в принципе невозможно по требованиям безопасности, в то время как протащить через файрволлы "честный" коннект к БД на один порт - вполне реально.
в любом случае, расшаривать папки не только неправильно, но и совсем необязательно. во-первых, можно написать свой простенький сервер приложений, который будет сам подбирать нужные файлы и отдавать клиенту по запросу.
во-вторых, практически все СУБД имеют возможность задавать собственные функции, например, в FireBird это UDF - User Defined Function, которые пишутся на любом языке, компилируются в dll, регистрируются в СУБД, и после этого они могут вызываться как обычные встроенные функции в селектах, хранимках и пр. т.е. вы пишете функцию, например, на паскале, которая по заданному пути считывает файл и возвращает его, например, как строку или xml с секцией CDATA. подключаете её к СУБД, и дальше запрос будет выглядеть, как select ID, udf_getfile (PATH) from table. дальше на клиентском приложении останется выковырять этот файл из его строкового представления.
поэтому можно хранить и ссылками, и без всяких шар. но у этого подхода есть один крайне жопный момент: ломается весь механизм реляционной СУБД. не только транзакции, а вообще всё на свете, начиная от обеспечения логической целостности и заканчивая механизмами кэширования чтения/записи. по сути, вы исскусственно выводите часть информации из под управления СУБД со всеми отсюда вытекающими. единственный резон, который может всё это перевесить - это размеры файлов: пихать в БД фото спутниковых сьёмок по 2-3 гига весом наверное, таки не стоит.
во всех остальных случаях - файлы лучше хранить в базе
