9 октября 2012 г., 12:59 пользователь Михаил Монашёв <postmas...@softsearch.ru> написал: > Здравствуйте, Dmitry. > snip... > Я бы здесь обсудил, ибо это удобнее. Идти куда-то не хочется. А > сказать мне есть что. Например, в языках программирования для > увеличения скорости работы с большими объектами используют указатели > на объекты. Так и у тебя можно: файлы лежат в хранилище неподвижно, а > работаешь ты только с описаниями этих файлов, содержащих всю > необходимую инфу о файле, включая его местоположение в хранилище. C > хранилищем работать можно через WebDAV.
Меня тоже занимает эта проблема в основном в свете конкретных плюсов/минусов хранения блобов в БД. Сейчас у меня мысли следующие: 1. Если строить архитектуру так, что хранить файлы в FS, а в БД только мета-инфу о них. + надежно, проверенно временем - сложно, нужны механизмы синхронизации мета-информации с контентом, обо всем этом надо задумываться * а если файл удалили в FS? * а как написать код, который, если не получилось сохранить файл не запишет в БД мета-инфу и наоборот... * а что с расширяемостью? с миграцией файлов? и т.д. и т.п. - сложно организовать контроль доступа 2. Если держать в БД целиком все, вместе с контентом + многие вещи упрощаются, логически единый интерфейс, транзакционность - стремно, как современные БД себя при этом ведут, что у них с расширяемостью - а что с производительностью, придется контент гонять не супер-оптимизированным решением fs->front->user, а странным bd->backend->front->user, страшновато + контроль доступа реализуется "на ура", т.к. все через бэк гонится Есть более контретные мысли? -- Vladimir Timofeev <vovk...@gmail.com> -- Moscow.pm mailing list moscow-pm@pm.org | http://moscow.pm.org