Здравствуйте, Baiker, Вы писали:

B>·>Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо.
B>Я и предлагаю СРАЗУ обойти грабли, чтобы потом, когда навалится тонна задач, не бегать и жевать сопли "а я не знал, что база будет большая!". Профи должен чувствовать проблемы интуитивно.
Так ведь история повторяется: "нагородил непонятную кучу проблем". Ты эти проблемы вообще не понимаешь и не чувствуешь. Потерять-поломать файлы — как нефиг делать, субд же заставляет за целостностью следить. Ну будет у тебя в базе uuid, а файл пропал или поменялся на что-то другое.
Да банально изменение файла сделать транзакционным — уже надо действовать с осторожностью. А ещё конкурентный доступ, локи, етс.
А с блобом у тебя полный acid из коробки.

B>·>Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял?
B>·>Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы?
B>Ты нагородил непонятную кучу проблем. Суть решения в том, что файл остаётся файлом. С соотв. удобствами по его нативной обработке: картинки — фотошопить, доки — конвертить, музыку — ужимать и т.п. А уж расшаривать папочку или копировать... ты серьёзно обсуждаешь эту чушь??
Серьёзно. Ибо эти файлы не просто так файлы, а связаны неявно с сущностями в бд. И у тебя не просто файлы, а файлы доступные из аппа и связанные с определённой бизнес-логикой.

B>·>В общем, конечно же, можно сделать всё своё, но это, повторюсь зависит от задачи и требований
B>Почти не зависит. Файл есть файл, в БД ему делать нечего. Абстрактный blob, о котором знает только апп.сервер — да, можно хранить. Всё остальное лучше внешне.
Чем абстрактный блоб принципиально от файла отличается?

Здравствуйте, Baiker, Вы писали:

B>·>Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо.
B>Я и предлагаю СРАЗУ обойти грабли, чтобы потом, когда навалится тонна задач, не бегать и жевать сопли "а я не знал, что база будет большая!". Профи должен чувствовать проблемы интуитивно.
Так ведь история повторяется: "нагородил непонятную кучу проблем". Ты эти проблемы вообще не понимаешь и не чувствуешь. Потерять-поломать файлы — как нефиг делать, субд же заставляет за целостностью следить. Ну будет у тебя в базе uuid, а файл пропал или поменялся на что-то другое.
Да банально изменение файла сделать транзакционным — уже надо действовать с осторожностью. А ещё конкурентный доступ, локи, етс.
А с блобом у тебя полный acid из коробки.

B>·>Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял?
B>·>Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы?
B>Ты нагородил непонятную кучу проблем. Суть решения в том, что файл остаётся файлом. С соотв. удобствами по его нативной обработке: картинки — фотошопить, доки — конвертить, музыку — ужимать и т.п. А уж расшаривать папочку или копировать... ты серьёзно обсуждаешь эту чушь??
Серьёзно. Ибо эти файлы не просто так файлы, а связаны неявно с сущностями в бд. И у тебя не просто файлы, а файлы доступные из аппа и связанные с определённой бизнес-логикой.

B>·>В общем, конечно же, можно сделать всё своё, но это, повторюсь зависит от задачи и требований
B>Почти не зависит. Файл есть файл, в БД ему делать нечего. Абстрактный blob, о котором знает только апп.сервер — да, можно хранить. Всё остальное лучше внешне.
Чем абстрактный блоб принципиально от файла отличается?