@Grundy привет. есть минутка?

@Bald привет!

что такое?

@Grundy да хотел пообщаться по архитектуре :)

@Bald :-D оооо, у меня с этим у самого проблемы :-D @Grundy не мочь в архитектура :)

@Grundy да ладно Тебе, не прибедняйся. счас напишу что за вопрос

не соображу как это сделать?

как вариант, сохранять в папку /images на сервере, а в таблицу ТипыИнструмента добавить поле типа строка, в котором будет путь к картинке

@Grundy ^^^

@Qwertiy ^^^

@Bald либо так либо пихать картинку в базу

какие размеры картинок ожидаются?

@Grundy что то наподобие таких ^

@Bald размер файлов какой? :-)

примерно :)

@Grundy ну эта картинка 33 кб

@Bald в принципе можно даже как base64 хранить

@Grundy страничка будет пухнуть если как base64 хранить

@Bald что значит пухнуть?

ты в любом случае будешь загружать эти картинки

@Grundy ну я же правильно понял, что отображение в этом случае будет выглядеть так: img src="data:image/png;base64,строкаBase64" ?

@Bald ага :-)

ну так src я так понимаю ты ж не вручную будешь вставлять

@Grundy нет конечно

@Bald ну тогда в чем проблема? :-)

@Grundy а если указывать как путь то в этом случае кэширование оптимизирует, или нет?

@Bald оптимизирует что?

@Grundy ну не каждый раз картинка будет запрашиваться с сервера, а достоваться из кэша. или я не о том?

@Bald ну как минимум один раз она должна будет загрузиться :)

base64-image.de попробуй здесь конвертнуть картинку в base64. строка не помещается в чат

@Bald На чём пишете? PHP или asp.net mvc?

@AK asp.net-mvc

@Bald По части того, где хранить картинки (в базе или на диске) я видел три подхода.

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

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

Ну и третий, когда контент сохраняется в БД, но тут же выгружается в некоторую папку кеша. При переносе сайта удобно держать скрипт, который выгрузит всё на диск. Двойные накладные расходы на хранение, но плюсы обоих подходов.

@AK спасибо, про третий я не слышал. у меня на текущий момент для некоторого контента используется 1 подход(выбрал его исходя из того что контент очень может быть тяжелым, на текущий момент самый здоровый файл весит около гига)

а общий объем контента 120 Гб

@Bald Нешто на сайте нет какого-то образцового вопроса на эту тему?

@AK я не смог найти, возможно есть на большом стаке

@Bald Даже и там особо нету (можете поискать по store images database), а если есть, то статьи каких-то древних годов. Я видел утверждения, что базы данных за последние лет пять уже достаточно хороши стали для того, чтобы можно было уже хранить в них картинки, но как-то голословно на мой взгляд. Вообще по хорошим практикам мне больше дало в этом плане изучение PHP фреймворков, а вот про c# based как-то мало инфы, я как-то уже спрашивал.

@AK при правильной схеме резервного копирования (т.е. отличной от варианта "делаем полный бэкап раз в день") нет никаких проблем с хранением файлов в нормальной СУБД.

@Bald Единственное что может помешать - это ограничение на размер базы если использовать бесплатный MSSQL Express

Если использовать платный MSSQL - то тяжелые файлы можно отдавать через nginx + FILESTREAM.

@PavelMayorov Накладные расходы на отдачу файла, лежащего на диске у веб-сервера будут намного ниже, чем в варианте "а ещё выполнить код на c# и ещё и в базу сходить", верно?

@AK nginx + FILESTREAM

Можно и через C# то же самое сделать, если аккуратно.

@PavelMayorov ок, понял. попадаю именно под это ограничение

@PavelMayorov Не слышал о таком варианте, спасибо за наводку. Был у меня как-то вопрос на тему выбора, на чём делать загрузку файлов, жаль раньше не подсказали подобный вариант.