sql >> Database teknologi >  >> NoSQL >> MongoDB

Lagring, organisering og forespørgsel på produkter, muligheder/tags og kategorier

Jeg driver også et e-handelswebsted. Her er mit råd til, hvordan jeg implementerer de funktioner, du nævnte. Håber det hjælper.

  • Kategorier

Jeg organiserer dem i en flad struktur, i dit tilfælde ville det være:

{_id:1, navn:"Elektronik", parentId:0, idPath:"/0/1/" ...} {_id:2, navn:"Computere", parentId:1, idPath :"/0/1/2/", ...} {_id:3, navn:"Grafikkort", parentId:2, idPath:"/0/1/2/3/", ...}

Og produktet skal nu kun være i bladkategorierne. I dit tilfælde:

 { _id:asdasfwetrw34tw34t245y45y, navn:"NVIDIA GTX670", pris:99,50, ... ... categoryIds:[3] } 

Produktet kan selvfølgelig være i flere kategorier, så categoryIds forbliver et array. Her er den vanskelige del. Når du angiver Elektronik kategori, kan du finde alle dens underkategorier ved at:

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

idPath indekset virker her, så det går hurtigt. når du finder ud af alle underkategorierne, kan du nemt finde alle produkterne i dem (byg indeks på categoryIds af Produkt samling).

Eller alternativt kan du læse alle kategorierne ind i hukommelsen og bygge en hash-tabel med key->categoryId, value->[alle underkategorierne]. Dine kategorier ændres normalt ikke ofte, og du vil ikke have mange kategorier. Så det bliver fint.

  • Tags/indstillinger

Først og fremmest tror jeg, at der er noget galt med din kategori. Kvindemode er noget generisk, bør du sætte dit produkt ind i noget mere specifikt, og mulighederne bør også være der. For eksempel kan der være en kategori frakke som har størrelsen &farve , bortset fra mode til kvinder . Selvom der stadig kan være farve mulighed på kvindemode fordi det er et fælles kendetegn for alle underkategorier.
Hvis du tænker over det, hvorfor er alle underkategorierne organiseret i én overordnet kategori? fordi de har noget til fælles. Denne fælles del bør være de fælles muligheder for overordnet kategori. det vil sige, at der skal være en arv mellem alle overordnede kategorier og underkategorier. For eksempel:

Derefter frakke ville endelig have 2 muligheder farve &størrelse . solbriller :farve &form . Når du ser mode til kvinder , der er kun 1 mulighed farve . Det filtrerer også underkategorierne, fordi de arver fra kvindemode .
Med hensyn til farveværdierne er min idé kun at bruge standardfarverne Strawberry Red er faktisk rød , Tangerine er faktisk orange . Du ønsker ikke rigtig, at de skal vises, når du filtrerer produkterne. Ellers ville der være for mange muligheder, bestemt ikke godt for brugeroplevelsen.
Men udover farve mulighed fra kategorien, har mit websted også noget, der hedder tilpassede indstillinger . Disse muligheder er kun defineret på produkterne. De vises aldrig, når du ser kategori. Her kan du få Strawberry Red &Tangerine . Efter min mening er disse ikke 'naturlige' egenskaber ved et produkt. De bruges kun til at få brugeren til at føle sig mere komfortabel, når de ser produktet. Således kan du også have mulighed af denne art som Tangerine med figur osv.
En ting mere om muligheder. du vil måske markere, hvilke muligheder der skal bruges til at filtrere produkter. For eksempel farve er bestemt en. Mens dimension måske ikke.

Om typer af muligheder. Dine har det fint, hvis det er nok for dig. Jeg har mange flere typer såsom Number , String , Enkeltvalg , Flere valg . Jeg planlægger også at implementere Unit . En vanskelig del af Unit er det for eksempel

1 GB =1024 MB =1024*1024B 

Så når du får en harddisk på 1GB og 1TB, vil du måske lave en konvertering, før du filtrerer produkter. Dette er uden for emnet, jeg vender tilbage til dit spørgsmål.

Bemærk, at selvom mulighederne for forskellige kategorier har samme navn. De er sandsynligvis ikke det samme. Materiale af Frakke og Møbler er 2 forskellige ting. Så jeg har en tendens til at definere forskellige muligheder for forskellige kategorier. Således er der måske farve for legetøj , og farve til mode til kvinder . Dette er ikke i konflikt med arven nævnt ovenfor, fordi fra et eller andet niveau begynder underkategorierne at dele de samme muligheder. Dette er fuldstændigt relateret til, hvordan du organiserer din kategoristruktur. Og hvis du vil ændre kategoristruktur eller flytte produkter på et stykke tid, ville det være smertefuldt. Så vær forsigtig, når du definerer dine kategorier.

Det er alt, der kommer op i mit sind. Jeg er bange for, at jeg ikke har engelsk som modersmål, så du kan finde en del af mit svar svært at forstå. Du er velkommen til at fortælle mig det.




  1. Operationel databaseadministration

  2. Forbindelsesstreng i MongoDB (med eksempler)

  3. Implementer MongoDB i en Amazon Virtual Private Cloud (VPC)

  4. mongoDB:$inc af et ikke-eksisterende dokument i et array