Структура базы данных MySQL для бесконечного количества элементов на пользователя
У меня есть база данных MySQL с растущим числом пользователей, и у каждого пользователя есть список предметов, которые они хотят, и предметов, которые у них есть, и у каждого пользователя есть определенный идентификатор
Текущая база данных была создана некоторое время назад, и в настоящее время у каждого пользователя есть определенная строка в таблице "ХОЧУ" или "ЕСТЬ" с 50 столбцами в строке с идентификатором пользователя в качестве первичного ключа, и у каждого элемента "ХОЧУ" или "ЕСТЬ" есть определенный идентификационный номер.
В настоящее время это ограничивает добавление 50 элементов на пользователя и значительно усложняет поиск и другие функции с базами данных
При повторном обновлении базы данных - было бы целесообразно вместо этого просто создать 2 столбца и иметь таблицу с каждой строкой, имеющей идентификатор пользователя и идентификатор элемента. Таким образом, нет "теоретического" ограничения на количество элементов на одного пользователя.
Каждый раз, когда участник загружает страницу профиля, список его желаний и имеющихся элементов будет составляться с помощью простого оператора SELECT WHERE ID = ##### из таблицы "Иметь или хотеть"
Кроме того, я потребуется сравнить списки элементов пользователя и пользователя, наиболее распространенные элементы, пользователя с большинством элементов, выполнить поиск элементов, которые нужны одному пользователю, а у другого пользователя есть... - бла-бла-бла
Количество пользователей будет варьироваться от 5000 до 20000
И каждый пользователь в среднем составляет около 15-20 элементов
Будет ли это жизнеспособной структурой MySQL или мне придется пересмотреть свою стратегию?
Большое спасибо за вашу помощь!
4 answers
Это, безусловно, будет жизнеспособной структурой в mysql. Он может обрабатывать очень большие объемы данных. Однако при его создании убедитесь, что вы установили правильные индексы для идентификаторов пользователей/элементов, чтобы запросы возвращались быстро и быстро.
Это называется отношением "один ко многим" в терминах базы данных.
Table1 holds:
userName | ID
Table2 holds:
userID | ItemID
Вы просто помещаете во вторую таблицу столько строк, сколько хотите.
В вашем случае я бы, вероятно, структурировал таблицы следующим образом:
users
id | userName | otherFieldsAsNeeded
items
userID | itemID | needWantID
Таким образом, вы может быть либо простой поиск для needWantID - например, 1 для потребности, 2 для желания. Но позже вы можете добавить 3 для списка желаний, например.
Изменить: просто убедитесь, что вы не храните информацию о своем товаре в таблице items просто сохраните отношение пользователя к товару. Имейте всю информацию о товарах в таблице (например, в описаниях товаров), в которой содержатся ваши описания, цены и все, что вы хотите.
Я бы рекомендовал 2 таблицы, таблицу "Хочет" и таблицу "Есть". Каждая таблица будет иметь идентификатор пользователя и идентификатор продукта. Я думаю, что это наиболее нормализованный и дает вам "неограниченное" количество элементов на пользователя.
Или у вас может быть одна таблица с идентификатором пользователя, идентификатором продукта и типом ("ХОЧУ" или "ЕСТЬ"). Я бы, вероятно, выбрал вариант 1.
Как вы упомянули в своем вопросе, да, было бы гораздо разумнее иметь отдельные таблицы для нуждающихся и имущих. В этих таблицах может быть столбец идентификатора, который будет связывать строку с пользователем, и столбец, который фактически определяет, что НУЖНО или ЕСТЬ элемент. Этот метод позволил бы значительно расширить пространство для расширения.
Следует отметить, что если у вас много таких строк, вам может потребоваться увеличить пропускную способность вашего сервера, чтобы поддерживать быстрые запросы. Если ты имейте миллионы строк, они будут иметь большую нагрузку на сервер (в зависимости от вашей настройки).
То, что вы теоретизируете, - это очень законная структура базы данных. Для отношений many to many (которые вы хотите), единственный способ, которым я видел, как это делается, - это, как вы говорите, иметь таблицу отношений с идентификатором пользователя и item_it в качестве столбцов. Вы могли бы подробнее остановиться на этом, но это основная идея.
Этот дизайн намного более гибкий и позволяет создавать бесконечное количество элементов для каждого пользователя, которые вы хотите.
Для того, чтобы справиться с желаниями и иметь, вы можете создать две таблицы или вы можно было бы просто использовать один и иметь третий столбец, в котором содержался бы всего один байт, указывающий, является ли совпадение пользователя/элемента желаемым или необходимым. В зависимости от специфики ваших проектов, любой из них будет жизнеспособным вариантом.
Итак, в итоге вы получите, по крайней мере, следующие таблицы:
Table: users
Cols:
user_id
any other user info
Table: relationships
Cols:
user_id
item_id
type (1 byte/boolean)
Table: items
Cols:
item_id
any other item info
Надеюсь, это поможет!