Моделиране на бази данни:Как да категоризираме продукти като Amazon?

Разбира се, че ще се мащабира. Това ще работи добре, това е често използвана структура.

Включете level_no . Това ще помогне в кода, но по-важното е, че е необходимо да се изключат дубликати.

Ако искате наистина стегната структура, имате нужда от нещо като Unix концепцията за inodes.

Може да имате затруднения да се ориентирате в кода, необходим за създаване на йерархията, да речем от product , но това е отделен въпрос.

И моля променете

• (product_category )) id към product_category_id
• (product id към product_id
• parent_id към parent_product_category_id

Отговори на коментари

1. level_no . Разгледайте този модел на данни, той е за структура на дървото на директории (напр. прозореца на FlieManager Explorer):

   Модел на данни за указател

   Вижте дали можете да го разберете, това е концепцията на Unix inode. Имената на файлове трябва да са уникални в рамките на възела, следователно вторият индекс. Това всъщност е завършено, но някои разработчици в наши дни ще имат затруднения да напишат кода, необходим за навигация в йерархията, нивата. Тези разработчици се нуждаят от level_no за да идентифицират с какво ниво в йерархията работят.

2. Препоръчителни промени. Да, нарича се „Конвенции за добро именуване“. Аз съм твърд по отношение на това и го публикувам, така че това е стандарт за именуване. Има си причини за това, които ще ви станат ясни, когато напишете някакъв SQL с 3 или 4 нива на присъединяване; особено когато отидете при един и същ родител по два различни начина. Ако търсите SO, ще намерите много въпроси за това; винаги един и същ отговор. Ще бъде подчертано и в следващия модел, който пиша за вас.