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 index यहां काम करता है इसलिए यह तेज होने वाला है। जब आप सभी उप-श्रेणियों का पता लगा लेते हैं, तो आप उनमें सभी उत्पाद आसानी से ढूंढ सकते हैं (categoryIds पर अनुक्रमणिका बनाएं) Product . का संग्रह)।

या वैकल्पिक रूप से, आप सभी श्रेणियों को मेमोरी में पढ़ सकते हैं और कुंजी-> श्रेणी आईडी, मान-> [सभी उपश्रेणियों] के साथ हैश तालिका बना सकते हैं। आपकी श्रेणियां आमतौर पर बार-बार नहीं बदलेंगी और आपके पास बहुत सारी श्रेणियां नहीं होंगी। इस प्रकार यह ठीक रहेगा।

  • टैग/विकल्प

सबसे पहले मुझे लगता है कि आपकी श्रेणी में कुछ गड़बड़ है। 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

इसलिए जब आपको 1GB और 1TB की हार्ड डिस्क मिलती है, तो आप उत्पादों को फ़िल्टर करने से पहले एक रूपांतरण करना चाह सकते हैं। यह विषय से हटकर है, मैं आपके प्रश्न पर वापस आता हूँ।

ध्यान दें कि हालांकि विभिन्न श्रेणियों के विकल्पों का एक ही नाम है। वे एक ही बात की संभावना नहीं है। Material coat . का और Furniture 2 अलग चीजें हैं। इसलिए मैं विभिन्न श्रेणियों के लिए अलग-अलग विकल्पों को परिभाषित करता हूं। इस प्रकार शायद color toys . के लिए , और color women fashion . के लिए . यह ऊपर वर्णित विरासत के साथ संघर्ष नहीं करता है क्योंकि कुछ स्तर से, उपश्रेणियां समान विकल्पों को साझा करना शुरू कर देती हैं। यह पूरी तरह से संबंधित है कि आप अपनी श्रेणी संरचना को कैसे व्यवस्थित करते हैं। और अगर आप श्रेणी संरचना को बदलना चाहते हैं या उत्पादों को कुछ समय के लिए स्थानांतरित करना चाहते हैं, तो यह दर्दनाक होगा। इसलिए अपनी श्रेणियां निर्धारित करते समय सावधान रहें।

मेरे दिमाग में बस इतना ही आता है। मुझे डर है कि मैं मूल अंग्रेजी बोलने वाला नहीं हूं इसलिए आपको मेरे उत्तर का कुछ हिस्सा समझने में मुश्किल हो सकती है। बेझिझक मुझे बताएं।




  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. पार्स सर्वर के साथ मोंगो/बीएसओएन ऑब्जेक्ट आईडी का उपयोग करना

  2. संबंधित दस्तावेजों की गणना करने के लिए MongoDB सर्वोत्तम अभ्यास

  3. सरणी के साथ दस्तावेज़ खोजें जिसमें एक विशिष्ट मान हो

  4. रेल ऐप पर रूबी से मोंगोडब डेटाबेस और संग्रह सूची की सूची कैसे प्राप्त करें?

  5. MongoDB:क्रॉस-संग्रह क्वेरी