MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Запазване, организиране и търсене на продукти, опции/тагове и категории

Аз също управлявам уебсайт за електронна търговия. Ето моят съвет как да внедря функциите, които споменахте. Надявам се да помогне.

  • Категории

Организирам ги в плоска структура, във вашия случай това би било:

    {_id: 1, name: "Electronics", parentId: 0, idPath: "/0/1/" ...}
    {_id: 2, name: "Computers", parentId: 1, idPath: "/0/1/2/", ...}
    {_id: 3, name: "Graphic Cards", parentId: 2, idPath: "/0/1/2/3/", ...}

И продуктът вече трябва да бъде само в категориите листа. Във вашия случай:

    {
        _id: asdasfwetrw34tw34t245y45y,
        name: "NVIDIA GTX670",
        price: 99.50,
        ...
        ...
        categoryIds: [3]
    }

Продуктът може да бъде в няколко категории, разбира се, така че categoryIds остава масив. Ето сложната част. Когато изброявате Electronics категория, можете да намерите всички нейни подкатегории от:

    db.categories.find({idPath: /^\/0\/1/})

idPath индексът работи тук, така че ще бъде бърз. когато откриете всички подкатегории, можете лесно да намерите всички продукти в тях (изградете индекс на categoryIds на Product колекция).

Или алтернативно, можете да прочетете всички категории в паметта и да изградите хеш таблица с ключ->categoryId, стойност->[всички подкатегории]. Вашите категории обикновено няма да се променят често и няма да имате много категории. Така че всичко ще бъде наред.

  • Етикети/Опции

Първо, мисля, че нещо не е наред с вашата категория. Women fashion е нещо общо, трябва да поставите продукта си в нещо по-специфично и опциите също трябва да са там. Например, може би има категория coat който има size &color , различни от women fashion . Въпреки че все още може да има color опция в women fashion защото това е обща характеристика на всички подкатегории.
Ако се замислите, защо всички подкатегории са организирани в една родителска категория? защото имат нещо общо. Тази обща част трябва да бъдат общите опции на родителската категория. това означава, че трябва да има наследство между всички родителски категории и подкатегории. Например:

След това coat накрая ще има 2 опции color &size . sun glasses :color &shape . Когато разглеждате women fashion , има само 1 опция color . Филтрира и подкатегориите, защото те наследяват от women fashion .
Що се отнася до стойностите на цвета, идеята ми е да използвам само стандартните цветове Strawberry Red всъщност е red , Tangerine всъщност е orange . Всъщност не искате те да се показват, когато филтрирате продуктите. В противен случай ще има твърде много опции, определено не е добре за потребителското изживяване.
Въпреки това, освен color опция от категорията, моят сайт също има нещо, наречено customizable options . Тези опции са определени само за продуктите. Те никога не се появяват, когато преглеждате категория. Тук можете да имате Strawberry Red &Tangerine . Според мен това не са „естествени“ свойства на продукта. Те се използват само за да накарат потребителя да се чувства по-комфортно при разглеждане на продукта. По този начин също можете да имате опция от този вид като Tangerine with figure и т.н.
Още нещо за опциите. може да искате да маркирате кои опции трябва да се използват за филтриране на продукти. Например color определено е един. Докато dimension може и да не е.

Относно видовете опции. Твоите са добре, ако са ти достатъчни. Имам много повече типове като Number , String , Single Choice , Multiple Choices . Също така планирам да внедря Unit . Трудна част от Unit това е например

1GB = 1024MB = 1024*1024B

Така че, когато получите твърд диск от 1 GB и 1 TB, може да искате да направите преобразуване, преди да филтрирате продукти. Това не е по темата, ще се върна на въпроса ви.

Имайте предвид, че въпреки че опциите на различните категории имат едно и също име. Те вероятно не са едно и също нещо. Material на Coat и Furniture са 2 различни неща. Така че съм склонен да дефинирам различни опции за различните категории. Следователно може би има color за toys и color за women fashion . Това не е в конфликт с наследяването, споменато по-горе, защото от известно ниво подкатегориите започват да споделят едни и същи опции. Това е напълно свързано с това как организирате структурата на вашата категория. И ако искате да промените структурата на категорията или да преместите продукти известно време, би било болезнено. Така че бъдете внимателни, когато определяте категориите си.

Това е всичко, което ми идва наум. Опасявам се, че не съм роден английски, така че може да намерите част от отговора ми трудна за разбиране. Чувствайте се свободни да ме уведомите.




  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Невалидна схема, очаква се „mongodb“ или „mongodb+srv“.

  2. Как да актуализирам _id на един MongoDB документ?

  3. Как да групирате данни с помощта на mongo-шаблон

  4. Актуализирайте много, ако съществува, в противен случай създайте нов документ за всеки LeadId, който не съществува

  5. NotUniqueError:Опит за запазване на дублирани уникални ключове