база данных с категорией (необязательная подкатегория) и подкатегорией (услуга)

Question

Думаю, я справлюсь со всем этим самостоятельно, но ... я думаю, что я потратил слишком много времени ... Привет всем!Я борюсь со структурой базы данных Room - я не уверен, верен ли мой подход или нет.Я пытаюсь добиться того, чтобы иметь возможность добавлять Сервисы (подкатегории) в Категории, но также могут быть дополнительные Подкатегории:

Категория -> Сервис

Категория ->необязательная подкатегория -> Служба

То, что я уже сделал (пропустил некоторые основные части кода):

a) созданные объекты

@Entity
class Category
int id
String name

@Entity
class Subcategory
int id
String name
int categoryID

@Entity
class Subcategory
int id
String name
int categoryID
int subcategoryID

b) созданные таблицы соединений

@Entity
class Join
int id
int categoryID
int subcategoryID
int serviceID

Это просто, когда у категории есть подкатегория с любыми услугами:

id | categoryId | SubcategoryId| ServiceId|
-------------------------------------------
1  |          1 |            1 |        1 |
1  |          1 |            1 |        2 |

, но если нет подкатегории, и услуга принадлежит только к категории:

id | categoryId | SubcategoryId| ServiceId|
-------------------------------------------
1  |          1 |         null |        1 |

Я поставил null в качестве SubcategoryId и проверил, является ли подкатегория нулевой

Итак, вопрос в следующем: Является ли этот подход правильным с точки зрения проектирования реляционных баз данных?

Или я должен: 1. создать таблицы подкатегорий категории-подкатегории, службы подкатегории, категории-службы и каким-то образом объединить их в конечном итоге в одно большое соединение?2. или добавить к сервису categoryId и subcategoryId?

Любые комментарии, советы и рекомендации очень ценятся!:)

Answer 1

Существует старый дизайн под названием Nested Set.Преимущества этого дизайна в том, что он относительно прост, и вы можете создавать категории и подкатегории на любую глубину.Запросы являются быстрыми и могут извлекать данные различными способами: например, показывать подкатегории определенной категории, находящиеся на уровне 4.

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

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

Если это соответствует вашим потребностям, я предоставлю более подробную информацию в этом ответе вместе с большим количеством примеров кода.

Answer 2

Вместо того, чтобы объединять в другие реляционные таблицы, я бы использовал следующий подход:

Допустим, у вас есть только две категории, одна первичная (основная категория) & second это вторичная категория (подкатегория) .

Я бы создал сущность для Category в одной таблице, например:

@Entity
class Category
int id // It's our primary key here
String name
int parentId // To detect if category is Main/Sub. How? "Null" if Main, "main category" id if child

Теперь о Service сущности:

@Entity
class Service
int id
String name
//This is our foreign key from Category table
int categoryId //It can be Main/Sub category id from "Category" Table, how to detect it's Main/Sub? Check it from category table using "parentId".

Почему этот подход?

Потому что,

1 Сервис полагается на Категорию, поэтому для Сервиса не имеет значения, является ли Категория Основной / Суб.Все, что он знает, это то, что это категория для себя.

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