Производительность в таблицах с двоичными данными/изображениями
-
16-09-2019 - |
Вопрос
Я сделал экран обслуживания людей. Клиент хочет, чтобы я хранил фотографию каждого человека в базе данных, и я сделал это без проблем. У меня есть отдельная таблица для изображений с двумя полями, id_person и изображением.
Я немного волнуюсь, потому что я впервые работаю с изображениями в базе данных. Будут ли у меня проблемы с производительностью, когда таблица вырастет за пределами 1000/5000 изображений? Я полагаю, что размер каждого изображения будет иметь значение. Я уверен, что мне нужно будет контролировать, чтобы пользователь не сохранял очень большие изображения в базе данных.
Что будет хорошим ограничением размера? Клиенту нужны только фото лица, но я уверен, что кто -то попытается сделать фото с камерой «последней модели» в полном качеством;)
Спасибо.
Решение
Обычно предпочтительнее хранить папку изображений, а БД - просто ссылается на эту папку. В идеале, у каждого человека есть уникальный идентификатор, а файлы в папке «Изображения» соответствуют этому идентификатору.
Если вы действительно хотите сохранить двоичные данные напрямую, вы можете получить разумную качественную фотографию в 8 КБ от JPEG (около 250x250 пикселей при качеством 25%). Конечно, это было бы неприемлемо для печати, но это хорошо для идентификации.
Только вы узнаете, можете ли вы принять дополнительную 8 КБ на строку на сервере базы данных.
Другие советы
Если вы абсолютно должны сделать это таким образом, я бы сказал, ограничьте это всего лишь несколько килобитов каждый. Тем не менее, каждый администратор базы данных в мире, вероятно, скажет вам, что привязки изображений в поле базы данных - очень, очень плохая идея. Наиболее заметно вы увидите, как производительность резко снижается, когда файл базы данных вырос за пределы двух гигабайт по размеру.
Я бы предпочел сделать, как сказал Jheddings, и иметь папку с идентификатором каждого человека, и это имя файла и просто использовать стандартный .jpg или что -то в этом роде после этого в сети, чтобы все компьютеры, использующие приложение, могли получить доступ к изображениям.
Некоторые считают, что простой использование идентификатора недостаточно хорошо, если фотография должна быть удалена или архивирована, и в этом случае они поместят поле NVARCHAR (MAX) в свою базу данных и сохранит путь сетевого файла на изображение вместо фактического изображение.
Я бы помахивал изображение только в том случае, если ваш клиент абсолютно не может иметь пути обмена сетью.
Пока он находится в отдельной таблице с идентификатором | Blob, только не должны каких -либо проблем с производительностью, но с другой стороны, я предпочитаю держать в DB ссылки только на файлы на HDD (или даже лучше, если она единственная фотография пользователя, вы Не нужна ссылка, потому что пользователь с идентификатором 1 переходит в /images/1.jpg)