Архитектура базы данных MySQL - несколько типов взаимозависимых элементов

Question

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

Usecase:

Шаг 1- Пользователь решает использовать item1 и item2

Шаг 2 - Пользователь может выбрать item3 или item4, в зависимости от выбора на шаге 1

Шаг 3 - Пользователь может выбрать item5 илиitem6 или item7 или item8, в зависимости от выбора на шаге 1 и шаге 2

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

Я хотел бы получить совет по архитектуре базы данных.

Цель: опишите в базе данных, как itemX требует itemY (и, возможно, itemZ, itemN, ...)

Мне интересно, как эти зависимости могут быть реализованы в базе данных, потому что с тысячами строкиз 'switch's and' if в коде приложения просто не правильно.

Спасибо.

Answer 1

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

структура таблицы Join (assoc):

 product_id --- Enabled_product_Table --- Enabled_Product_Id

 Itemx          Table1                 ItemY
  .             Table2                 ItemZ

Теперь, когда вы запрашиваете зависимые записи, конечно, вам нужна дополнительная логика на уровне приложения (или вы можете написать это как процедуру) .. (точнее, вам нужно запустить запрос выбора в итерационном режиме, чтобы получить все зависимые продукты).

Если вы беспокоитесь о производительности, вы также можете сгруппировать enabled_product_ids определенной таблицы вместе. (в виде строки, разделенной запятыми, чтобы вы могли выполнить условие in) ...

Answer 2

со всем уважением, ваш вопрос должен называться как я анализирую / решаю проблемы! момент, когда вы думаете о пользовательском интерфейсе и прочем о дизайне и смешивании разговоров о item / itemType! случайные мысли [плохой мозговой штурм] увеличат время решения проблемы.

Подумайте об одном за раз, тогда со временем вы будете более способны обрабатывать различные входные данные, основываясь на фокусе и опыте!

Первое: исходя из чего, вы предполагали, что для каждого itemType требуется таблица / класс? поскольку объект с именем itemType, то все элементы должны принадлежать к СТРУКТУРЕ itemType, следовательно, по крайней мере, по [itemTypeId] правильно!

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

, поэтому, пожалуйста, отредактируйте вопрос и подумайте больше, чтобы получить больше!

удачи!

EDIT:
после редактирования вопроса, я понимаю, что проблема принадлежит [дизайн рабочего процесса]. с рабочим процессом вы можете перейти динамический или статический. Для динамических процессов требуются глубокие и глубокие знания в соединении узлов и их реализации, с другой стороны, «статические» просты в реализации, но требуют глубокого анализа проблемы, чтобы разбить каждую мелочь, о которой может подумать ваш мозг! для динамического рабочего процесса я настоятельно рекомендую изучить реализацию ms-sharepoint, так как она охватывает все это и позволяет просматривать структуру базы данных. [я помню, у них была огромная таблица в службе sharepoint 3.0, которая содержит более 100 столбцов, которые работают как базовая таблица, я думаю или, может быть, для аудита!] Другими словами, вам будет необходимо добавлять / удалять столбцы в таблицах, пока приложение во время выполнения и связать их с логикой приложения / процессом рабочего процесса. это основной источник трудностей динамического подхода. в больших масштабах это удалось сделать лишь немногим программным пакетам ERP, таким как SAP, SAGE, MS-Dynamics, Oracle Siebel crm. надеюсь, что это было полезно, я могу добавить больше, если нужно!