Дизайн базы данных MySQL - Хранение изображений - Одна таблица или несколько таблиц

В настоящее время я работаю над продуктом, в котором есть различные типы изображений, такие как изображения продукта, изображения профиля пользователя, логотип и т. Д. Мне нужна база данных с хорошей производительностью запросов.

Я задумал два проекта БД.

ВАРИАНТ 1. - Сохранение всех изображений в одной таблице с полями id, title, url_full, url_thumb, status и timestamp

Преимущества

  1. Я могу использовать один файл ImageModel для вставки данных удаления / обновления. Таким образом, не будет множественной логики для хранения изображений. Это всего лишь единая логика, «хранение в единой таблице». Поэтому всякий раз, когда нужно сохранить изображение, я могу вызвать метод ImageModel

Недостатки

  1. Если изображений продуктов много, а изображений пользователей меньше, запросы изображений пользователей станут медленными из-за огромного количества продуктов.

ВАРИАНТ 2. - Сохранение изображений разных типов в разных таблицах с полями id, title, url_full, url_thumb, status и timestamp

Преимущества

  1. Увеличение количества записей в одном разделе не повлияет на скорость запроса другого.

Недостатки

  1. Должен писать отдельные файлы модели / функции для каждого типа изображения.
  2. Каждый раз, когда изображение должно быть сохранено, необходимо указать тип.

Мой вопрос в том, какой подход лучше. Являются ли преимущества и недостатки реальной проблемой. Также, если есть какие-либо другие преимущества / недостатки, просьба перечислить. Или, если есть какие-либо другие проекты GoddB, пожалуйста, предложите.

Пожалуйста, ответьте, исходя из практического сценария, когда есть много продуктов и пользователей.


mysql architecture performance database-design code-maintainability
person Jinu Joseph Daniel    schedule 24.09.2016    source источник
comment
хорошая производительность запросов - пожалуйста, покажите нам запросы; без них мы не сможем вам помочь.   -  person Rick James    schedule 27.09.2016
comment
Какой типичный размер изображений? Если мы говорим о килобайтах, то лучше один ответ; мегабайты, тогда лучше другое.   -  person Rick James    schedule 27.09.2016

Ответы (2)


arrow_upward
8
arrow_downward

Это началось как длинный комментарий, поэтому я решил опубликовать его как ответ. Мне кажется, что хранить разные типы изображений в разных таблицах - плохая идея. Во-первых, как этот дизайн будет масштабироваться, если, например, позже появятся новые типы категорий? Сможете ли вы тогда справиться с добавлением произвольного количества новых таблиц изображений? Кроме того, запрос всех изображений потребует либо серии объединений, либо объединений, что может быть дорогостоящим.

Вы упомянули следующее преимущество схемы таблицы с несколькими изображениями:

Увеличение количества записей в одном разделе не повлияет на скорость запроса другого.

Если вы используете одну таблицу изображений с индексом в столбце type, то увеличение количества записей одного типа не обязательно приведет к увеличению количества запросов изображений второго типа. И вот недостаток одной таблицы изображений, которую вы указали:

Если изображений продуктов много, а изображений пользователей меньше, запросы изображений пользователей станут медленными из-за огромного количества продуктов.

Это правда, что добавление дополнительных записей обычно замедляет выполнение запросов. Однако наличие подходящего индекса для типа должно значительно уменьшить эту проблему.

Единая таблица изображений с соответствующими индексами кажется намного лучше.

person Tim Biegeleisen    schedule 24.09.2016
comment
Спасибо. На самом деле я запутался в предложениях других архитекторов в команде. Надеюсь, это, возможно, лучшая структура. - person Jinu Joseph Daniel; 24.09.2016
comment
Один из сценариев, в котором хранение изображений в отдельных таблицах может иметь смысл, может заключаться в том, что таблица просто слишком велика, например миллионы записей или больше. Но даже тогда вы бы просто сегментировали модель с одной таблицей. - person Tim Biegeleisen; 24.09.2016
comment
Наше приложение ориентировано на 2 миллиона пользователей ... и изначально будет около 75000 продуктов, которые со временем могут расширяться. - person Jinu Joseph Daniel; 24.09.2016
comment
Продукция 75K меня совсем не пугает, как и 750K. Если вы попадете в миллионы и производительность упадет, возможно, пришло время переосмыслить ситуацию. - person Tim Biegeleisen; 24.09.2016
comment
А вы знаете, на сколько процентов уменьшается скорость запросов на 10000 записей. Тоже экспоненциальное уменьшение ?? - person Jinu Joseph Daniel; 24.09.2016
comment
Это полностью зависит от таблицы, базы данных, трафика, количества пользователей и т. Д. - person Tim Biegeleisen; 24.09.2016

arrow_upward
-1
arrow_downward

Как вы доставите изображения? Если через <img src=http:...>, то ответ только один: отдельные файлы.

Да, эскизы можно создавать с помощью других механизмов, таких как преобразование в base64 и включение в тег img. Это может быть лучшим, если у вас много эскизов на странице.

Но наличие миниатюр в той же таблице, что и столбцы, которые вы запрашиваете, может отрицательно сказаться на производительности. Итак, нам нужно увидеть запросы и схему таблицы (в ее нынешнем виде).

person Rick James    schedule 26.09.2016