Использование MySQL для хранения путей к изображениям в JSON против строк / столбцов? - PullRequest
0 голосов
/ 26 апреля 2020

Я хочу создать приложение, в котором люди могут публиковать 20 различных категорий изображений, и для каждой категории вы можете добавить до 20 изображений.

Если бы у меня было 100 000 пользователей, это огромное количество строк, к которым я мог бы обратиться, чтобы получить фотографии для одного пользователя.

Мой вопрос: JSON более быстрая или медленная альтернатива?

У каждого пользователя может быть, возможно, 20 столбцов, в каждом из которых есть пятно JSON фотографий в каждом, или, альтернативно, один столбец с шариком JSON, содержащий все фотографии в соответствующих категориях.

Каждая фотография должна иметь возможность удаления или обновления, а также некоторую дополнительную информацию, такую ​​как дата загрузки и т. Д. c ...

В чем различия, в чем ваша рекомендация?

спасибо!

Ответы [ 2 ]

1 голос
/ 26 апреля 2020

Если вы ищете производительность, вы должны выбрать их индексирование, а не сохранять их как JSON значения. надо проверить это

0 голосов
/ 07 мая 2020

Обычно я не стал бы уделять этому вопросу много внимания. Но вы предлагаете 100 000 пользователей, каждый из которых имеет до 400 URL. Это становится громоздким с любым подходом. Но сначала посмотрите, нужно ли вам использовать План B:

План A: Если вы никогда не будете использовать MySQL для поиска по содержимому столбца, тогда вы можете поместить все ты хочешь в это. Если клиент хочет выделить содержимое столбца, тогда, конечно, используйте JSON (или любой другой), чтобы сделать это проще. И вы можете сэкономить место, сжимая столбец в клиенте и используя BLOB вместо JSON.

Plan B: Если, с другой стороны, вы хотите, чтобы MySQL выбирал строки на основе какая-то часть столбца, затем не скрывайте ее в середине столбца. Кроме того, у вас не должно быть 20 столбцов для 20 виджетов.

Если вы решите go с планом А, то есть еще одна проблема, которая может иметь значение. Если в таблице есть громоздкие столбцы в столбце (и кажется, что 400 URL-адресов будут громоздкими), эти столбцы , вероятно, будут храниться "вне записи". Это подразумевает дополнительный удар по диску, чтобы получить его. Поэтому остерегайтесь использования SELECT *, когда вам не нужен этот столбец; то есть, укажите столбцы, которые вам нужны .

(может быть несколько советов; просьба сообщить подробности о вашем приложении.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...