управление и связывание иерархических данных

Question

Таким образом, в моей базе данных приложений есть объект бизнес-профиля, который имеет:

• один основной Категория (например, Ресторан, Гостиница, Больница, ... и т. Д.)
• неограниченно подкатегорий (например, пиццерия, итальянский ресторан и т. Д.)
• неограниченно продукты (например, сырная пицца, пицца пепперони, ...и т. д.)
• безлимитный услуги (например, трансфер, служба доставки и т. д.)

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

Первое: Я могу использовать что-то вроде Список смежностиМодель для определения неограниченных категорий и соответствующих им подкатегорий, но как насчет услуг и продуктов сущностей?как я могу связать их все друг с другом, зная, что услуги и продукты являются дочерними элементами подкатегории сущности?

На данный момент это то, чтоУ меня есть: Рисунок-1

Второй: Как я могу сопоставить каждый Бизнес-профиль с его Категория / подкатегории / продукты /услуги ?!так что я знаю, что каждый бизнес-профиль находится в какой категории и какие подкатегории / продукты / услуги есть у каждого бизнес-профиля.

Вот отображение, которое у меня есть на данный момент: Figure-2

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

Answer 1

Когда я читал этот вопрос, я волновался, что у него будет сложная древовидная структура, но пока вы читаете вашу работу, она очень чистая и простая.

Лично я думаю, что вы на правильном путии сделаю несколько замечаний:

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

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

  1. У вас нет произвольной глубины.У вас просто есть родители и подкатегории.
  2. Для чего-то вроде системы бизнес-категорий, количество записей может быть достаточно низким, поэтому не стоит добавлять дополнительную сложность.Вероятно, довольно быстро прочитать всю таблицу и сохранить ее в памяти.

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