5
Я знаю, что хранение изображений в виде BLOB в SQL не рекомендуется. Однако работа на моем локальном ПК и на сервере затрудняет синхронизацию изображений между ними. Будет ли еще причина не использовать BLOB только в качестве резервной копии, которая создавала бы кешированный файл локально (для статического обслуживания)?MySQL Store Image BLOB Плохая практика производительности
По существу, является ли производительность проблемой только при выборе столбца BLOB? Если единственным эффектом будет более крупная таблица, то я не вижу причины не связывать изображение напрямую с записью таблицы.
Я знаю, что это напрямую не ответил, но не могли бы вы уточнить, почему образы не могут быть разделены? Могут ли они размещаться на сервере онлайн (или CDN)? – 1mike12
@ 1mike12 В настоящее время все хранится локально, и все пути относятся к базовому каталогу/веб-сайту, чтобы упростить разработку в разных средах. Это намного легче, когда тестирование не нужно беспокоиться о разрыве производственного сайта. Центральная база данных MySQL. Возможно, в будущем я также переключусь на централизованную систему для изображений, но на данный момент это более общий вопрос SQL, частично из любопытства. – nebkat
Нет никакой хорошей или плохой практики хранения изображений (файлов) в поле BLOB. Это скорее зависит от потребностей. Основанный на предвзятости: я вообще не храню изображения в файловой системе в широкомасштабных приложениях Java EE (серьезно, я был полностью устал от этого в прошлом), поскольку они не могут быть синхронизированы с соответствующими операциями с базой данных, особенно, когда они отправляться на удаленный сервер EE. Небольшая потеря производительности и/или небольшая неэффективность базы данных менее важны, чем правильность и полнота. Кроме того, файлы, хранящиеся в базе данных, более безопасны. – Tiny