У меня есть опыт работы как с сохранением изображения в виде BLOB-объекта в СУБД, так и с сохранением ссылки на него в файловой системе / в URL-адресе.Я понял, что первый подход просто не масштабируемый.
Вот довольно предвзятый список вещей о каждом подходе.
Подход 1. Сохранение изображений в виде BLOB-объектов:
Минусы:
Когда количество изображений увеличивается, размер базы данных также увеличивается, и вы ограничены файловой системой, на которой работает ядро СУБД.
Когда вы хотите извлечь большое количество этих BLOB-объектов, и если они имеют большой размер, вы тратите впустую IO / bandwdith и загружаете свой движок СУБД.В идеале вы хотите, чтобы он имел короткие запросы, которые выполнялись быстро и перемещали небольшое количество байтов.Вы просто не сможете получить это, если сохраните данные в виде BLOB в своей реляционной базе данных.Хотя некоторые могут утверждать, что для повторяющихся запросов кэширование поможет, я буду утверждать, что если бы этих огромных кусков данных не было вообще, мне бы не пришлось помещать их в кеш.
Не существует надежного способа для администратора баз данных / менеджера контента легко извлекать содержимое большого двоичного объекта, находящегося в базе данных, например, чтобы проверить, не повреждено ли изображение.Он должен будет подключиться к БД и извлечь байты BLOB в некотором формате, а затем просмотреть его.Или, в качестве альтернативы, вы можете создать какую-то страницу, чтобы сделать это для него, но это было бы плохо составленным трюком, по моему честному мнению.
Плюсы:
- Вам не нужно полагаться на доступность файловых систем или внешних систем, на которых вы размещаете свои изображения.Вы, вероятно, написали бы немного меньше кода, и у вас был бы больший контроль над вашим кодом, поскольку все, что вы хотите, находится в вашей СУБД.
Подход 2. Сохранение изображений в видессылка на файловую систему / urls
Плюсы:
Значительно снижает нагрузку на производительность вашего СУБД.
Если вы храните изображения в виде ссылок, системный администратор / менеджер контента может легко проверить их, просто скопировав ссылку в браузере и убедившись, что она правильно отображается.
Если вы используете не внешнюю службу размещения изображений, а скорее внутреннюю, вы все равно сохраните большой контроль, имея возможность в будущем добавить больше серверов / файловых систем для размещения изображений.
Если у вас есть большое количество загружаемых изображений, и они не размещены вами, вы можете распределить большую нагрузку на сеть, таким образом делая время загрузки более быстрым.
Минусы:
- Все будет немного децентрализовано, добавляя некоторую сложность вашему приложению.Если вы используете внешний хостинг, он может быть недоступен, и вы не можете его контролировать.
В заключение я искренне рекомендую использовать второй подход.