> Если насрать на такую вещь как целостность данных то храни в файлах, если нет - то в блобах

Дружище, расскажите скорей, что такое "целостность данных" по отношению к фотографиям.

Автору: хранить файлы в базе данных следует тогда, когда СУБД делает это компактнее, чем файловая система. Впрочем, с выходом ext4 и этот критерий будет не актуальным. Для всех остальных случаев место хранения файлов (любых, не только графических) - файловая система. Те, кто советуют хранить файлы в базе данных, просто не знают, что такое файловые хранилища, каких размеров они бывают и как управляются.

> Naf наверно имел в виду немного другую ситуацию, когда в БД имеется ссылка на файл из файл-сервера.

Если бы он имел это в виду, то так бы и написал.

> Далее во время очередной транакции, имя файла в БД меняется, но на ФС по причине какой то коллизии
> обновиться не успевает.

Вы вообще понимаете, о чем говорите? Если есть файловый сервер с непосредственным доступом, то единственное, для чего может понадобиться база данных - индексирование его содержимого. И в базе данных будет лежать то, что наковыряли кривыми ручками юзеры. А если есть приложение для управления файлами, то никакого непосредственно доступа к файлам у юзеров нет и быть не может. В последнем случае вообще удобно иметь суррогатные имена файлов.

> И если при хранении в блобах эту ссылочную целостность обеспечивает СУБД,

Мне повторить критерий хранения файлов в базе данных или таки Вы его самостоятельно прочтете? Нет никакой необходимости хранить файлы в базе данных за исключением описанного в первом сообщении случая.

> он так и написал )))

Читать нужно то, что написано, а не между строк.

> Где я сказал про непосредственный доступ?

А кому придет в голову руками менять имена файлов, можете сказать?

> Вы имеете в виду компактность размещения байтов?

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

> Я лично это вообще не считаю за серьезный критерий, ибо это копейки.

Уважаемый дон представляет себе стоимость отказоустойчивых решений? Или языком потрепать пришел?

> Гораздо более серьезным подходом я считаю обеспечение СЦ - так как это критерий надежности системы.

Я читал и более глубокомысленные, и более глупые обоснования кривых рук, так что не удивили.

> Зачем считать, достаточно прикинуть что для БД в 10 терабайт, плюс минус несколько гигов накладных расходов - это копейки

Дружище, Вы никогда не видели баз данных размером в десять терабайт, никогда не делали их бэкап и не восстанавливали их. ОК, оставайтесь самоделкиным.

> Это же развод на флуд )))

Это попытка мягко намекнуть, что Вы написали абсолютную фигню. Для продолжающих тупить: стоимость решений будет различаться на порядок в лучшем случае.

> Элементарно: в таблице езь запись о пути к файлу, а самого файла нет - кто-то его удалил.

Кто его удалил, если доступ есть только у root'а и бота, который периодически занимается проверкой соответствия содержимого файловой системы и базы данных?

> а потом вдруг р-р-раз - сбой, и запись в таблице оказалась неудалённой, и что тогда?

Установили флаг, удалили файл, убедились, что его нет, установили второй флаг, увидели два флага, пометили данные удаленными. Где проблемы?

> Есть существенная разница: бэкапить 10 ТБайт или 10,3 Тб?

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

> Ага, че не на два :))

Может, и два. Зависит от размера базы данных. Включайте мозги, включайте. В одном случае будет нужен сервер для базы данных размером 10 Тб, в другом - сервер для базы данных размером на четыре порядка меньше + сервер(ы) для файлопомойки. Позвоните ближайшему интегратору, он назовет порядок сумм.

> C FS неизбежно возникают проблемы доступа. В БД эти проблемы решаются самой СУБД.

Никаких проблем нет. Непосредственного доступа к файлам у пользователей нет. Права доступа - аналогично правам доступа к любых другим сущностям базы данных.

> А если ваш процесс вылетел сразу после установления второго флага?

Дружище, транзакции в базе данных Вам тоже не знакомы? Еще только утро, а самоделкины уже конкретно задолбали.

> Это надо реализовывать, или оно само сделается?

На все идиотские вопросы нужно отвечать?

> Подумайте например над тем, как вы будет реализовывать откат транзакции.

Какой транзакции, уважаемый? Если файл не был удален, ничего страшного для базы данных не произошло.

> Может это будет для вас откровением

Видимо, это для Вас откровение, сколько времени занимает бэкап и восстановление базы данных размером 10 Тб.

> но современные СУБД могут работать в распределенном режиме

А бэкапиться частями они тоже уже научились?

В общем так, прекращайте [censored] мозги, собирайте стенд и тестируйте. Закончите - пишите о результатах. Мне пионерские речевки надоели.

> Если клиент-сервер то придется расшаривать каталоги

Не придется. Более того, юзер даже не будет знать, на каком физическом сервере размещен его файл.

> Двойная работа, к тому же у СУБД гибче возможности чем у ФС

Похоже, я плохо объяснил. Для пользователя файл будет обладать ровно теми же атрибутами доступа, что и любая другая сущность базы данных. Просто потому, что никто никакого другого интерфейса ему не даст. Для приложения количество файловых серверов не ограничено. Для каждого из файловых серверов есть аккаунты, под которыми и происходят изменения их содержимого. Об этих аккаунтах пользователь ничего не знает, у него есть доступ только к приложению.

Пионерам Goffman и igor250973. Юноши, прекращайте писать хрень.

> Это возможно если есть сервер приложений.

Упс. А другие варианты я не рассматривал.

Обсуждаемое файловое хранилище нет смысла проектировать отдельно, для простых задач достаточно ftp серверов. А вот в составе более сложной системы хранилище - абсолютно легитимная компонента. Причем, файлы в нем можно хранить как с контролем версий, так и без. Т. е. изначально имеем два варианта управления файлами, причем, каждый из которых может быть реализован более, чем одним способом. Imho ни о каком хранении файлов в базе данных речь изначально не идет.