Реляционная база данных MySQL с большими наборами данных, уникальная для каждого пользователя

Question

Я работаю над проектом, который включает в себя создание приложения в стиле социальной сети, позволяющего пользователям обмениваться информацией о запасах/товарах в своей сети (для поиска).

Я порядочный программист, но я, по общему признанию, не специалист по базам данных; тем более, когда дело доходит до проектирования базы данных. В настоящее время информация о пользователе/​​компании хранится через схему реляционной базы данных в MySQL, которая работает отлично.

Моя проблема заключается в том, что, хотя моя реляционная схема работает блестяще для информации о пользователях/компаниях, это путает меня о том, как внедрять информацию инвентаризации. Проблема в том, что каждый «список инвентаря» определенно содержит разные атрибуты, относящиеся к типу продукта, но идентичные атрибутам каждого другого продукта в списке. Моя первая мысль заключалась в создании таблицы для каждого «списка инвентаря». Тем не менее, я чувствую, что это было бы очень грязно и осложнило будущие попытки KDD. Я также (кратко) рассматривается с использованием «мастер инвентаризации» и хранения информации (например, переменные категории и данные в виде строки JSON. Но я полагал, что JSON строки MySQL просто стала больше боль в заднице.

Мой вопрос по существу в том, как кто-то другой может решить эту проблему? Или, в более общем плане, придерживаться принципов управления реляционными базами данных, каков «правильный» способ связывания уникальных больших наборов данных аналогичного типа с родительским пользователем? , Я знаю, что я мог бы легко создать что-то, что сработало бы, но я искренне интересуюсь консенсусом относительно того, как решить эту проблему.

Answer 1

Я бы прочитал этот пост: Entity Attribute Value Database vs. strict Relational Model Ecommerce

То, как я всегда это делал, состоит в том, чтобы создать базовую таблицу для инвентаря, в которой хранятся общепринятые поля. Идентификатор продукта, название продукта и т. Д.

Затем у вас есть другая таблица с динамическими атрибутами. Очень популярным примером является Wordpress. Если вы посмотрите на свою модель данных, они сильно используют эту идею.

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

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