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

B>Потому что не всё то зелёное, что летит. ДАЛЕКО не всё, что придумывают офисные "джамшуты" надо бежать реализовывать (яркий пример — EF).

B>Поначалу кажется да — всё засунули в БД — моногамия и красота! Но когда начнётся наполнение БД, а ты (очевидно) продолжаешь развивать систему, ты очень быстро придёшь к ситуации,
Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо.

B>Sharov>Почему нет, если, например, небольшие файлы 5-10мб типа картинок?

B>ТЕМ БОЛЕЕ картинки! (к примеру, картинки товаров) Сегодня ты наструячил мегабайтных 3Д картинок, а завтра манагер подходит: "Нам нужен мобильный вебсайт — чтобы все картинки были по 5К". И начинается!... Сначала картинки выгрузи, причём так, чтобы не похерить их ID, затем отдай дизайнеру, он их ужмёт, отдаст тебе, ты ЗАНОВО импортируешь картинки в базу или того хуже — будешь создавать ещё одно поле теперь уже для ужатых картинок, да ещё согласовывать, чтобы ужатая как-то соотносилась с неужатой... ой ё!
B>Т.е. буквально на ровном месте огребаешь кучу проблем (+ проблемы, которые я описал для vaa). Оно тебе надо?
Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял?
Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы?

B>Я почему так говорю — тоже как вы по-молодости вляпывался во всякие "инновации от M$". И повозившись с нехреновой такой "базой с картинками", плюнул и сделал всё на внешних файлах. В результате база — маленькая, легко и БЫСТРО бэкапится/сжимается, модифицировать её — вообще без проблем (хоть каждый день пересоздавай!), а файлы организовал независимым способом: каждый файл именуется GUID'ом, а затем применяется "партишенинг": первые две буквы имени являются именем подкаталога (от единого корневого), где файлы и лежат:
Тут появляются инфраструктурные проблемы как состояние базы синхронизировать с состоянием base_pic_dir.

B>Т.е. имеем распределённую систему файлов, чтобы не хранить миллиард фоток в одном каталоге.
B>Итого, чтобы мне перенести такую хренову тучу файлов в развёртываемую систему, мне достаточно из сархивировать и скопировать! Причём на любой носитель (не засирая системный с БД). Ну а в базе храним только имена конечных файлов, которые опять же легко переносятся, дополняются и т.п.
Недостаточно. А в БД можно _если надо_ настраивать чтобы табличка с файлами была на другом носителе.


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