2013-01-07 97 views
5

मैं श्रेणी में फ़िल्टरिंग उत्पादों को कार्यान्वित करना चाहता हूं और मेरे पास सही डीबी स्कीमा के बारे में प्रश्न हैं। अभी के लिए मेरे पास निम्न तालिकाओं:उत्पाद विशेषताओं के लिए डेटाबेस स्कीमा

श्रेणियाँ:

1. id 
2. category 
3. description 

उत्पाद:

1. id 
2. category_id 
3. product 
4. image 
5. price 

गुण:

1. id 
2. attribute 

Category_Attributes:

1. category_id 
2. attribute_id 

और सवाल मेरे पास है क्या टेबल मैं बनाना चाहिए और क्या कॉलम चिल्लाने वे मूल्यों के विभिन्न प्रकार के स्टोर करने के लिए किया है, विशेषता मान, उत्पादों विशेषता मान आदि

चाहेंगे

मान:

यह 3 से अधिक टेबल बनाने के लिए सामान्य हो 10

Attributes_Values ​​:

1. attribute_id 
2. value_id 

Products_Attributes_Values ​​:

1. product_id 
2. attribute_id 
3. value_id 

मैं पिछले तालिकाओं में में गड़बड़ कर दिया है। स्टोर और फ़िल्टर करने के लिए बेहतर क्या होगा?

+0

क्या आप अपनी अंतिम तीन तालिकाओं के साथ क्या हासिल करना चाहते हैं, इसके बारे में अधिक जानकारी दे सकते हैं? प्रत्येक टेबल क्या करना है? क्या मानक मानक सूची होने के लिए मूल्य हैं? क्या यह सूची श्रेणी पर निर्भर करती है? क्या किसी उत्पाद के लिए एक उत्पाद के लिए एक से अधिक मान हो सकते हैं? अपनी आवश्यकताओं को बेहतर तरीके से समझे बिना सलाह देना मुश्किल है। –

+0

उदाहरण के लिए मेरे पास "मोती" श्रेणी है, इसमें कुछ विशेषताएं होंगी: व्यास, सामग्री, पैकेजिंग। व्यास 8 मिमी, 10 मिमी, 12 मिमी आदि होगा, सामग्री प्लास्टिक, लकड़ी, कांच, धातु, सिरेमिक भी बदल सकती है। व्यवस्थापक क्षेत्र में मैं सभी विशेषताओं के लिए चयन करना चाहता हूं और केवल एक विकल्प चुनना चाहता हूं। और सूची में मैं अपने सामानों को स्वतंत्र रूप से फ़िल्टर करना चाहता हूं, उदाहरण के लिए मैं व्यास 10 मिमी, 12 मिमी, और सामग्री सिरेमिक के साथ मोती की तलाश में हूं। – UAMoto

+0

हां, प्रत्येक श्रेणी में इसके गुण होंगे और उन विशेषताओं के उनके मूल्य होंगे। – UAMoto

उत्तर

8

आप क्या हासिल करने की कोशिश कर रहे हैं एक इकाई-गुण-मूल्य (EAV) या संभवतः एक पंक्ति मॉडलिंग समाधान है। ध्यान दें कि इस तरह की संरचना काफी अच्छे कारणों से व्यापक रूप से फंस गई है।

हालांकि, मैं ने तर्क दिया है (उदाहरण के लिए here, here, here, और here) कि EAV बुराई है, जब यह नहीं है सिवाय। उन दुर्लभ अपवादों में से एक उत्पाद सूची के मामले में है जहां आप उत्पादों के गुणों को ट्रैक कर रहे हैं और जहां वे गुण आपकी रोचक नहीं हैं (आपके सिस्टम में!) इन्हें छोड़कर आपको इन्हें पुनर्प्राप्त करने और उन्हें प्रिंट करने की आवश्यकता है एक उत्पाद वेब पेज या एक तुलना ग्रिड, आदि पर

इस तरह एक डिजाइन पर विचार करें:

enter image description here

क्या आप इस तरह एक मॉडल में कर रहे हैं जो किसी एक श्रेणी में उत्पादों विशेषताओं का वर्णन किया गया है चाहिए होने के लिए, उन गुणों का क्या मूल्य हो सकता है, और उसके बाद प्रत्येक विशिष्ट उत्पाद के मूल्यों के लिए क्या होता है सी विशेषता।

इस डिज़ाइन में ईएवी लागू होने वाली सभी सामान्य सीमाएं होती हैं।हालांकि, अगर आप इस तरह के प्रश्न पूछना चाहते हैं: "कौन सा मोती 8 मिमी व्यास है?" वह बहुत सीधी है।

+0

यदि हम 'eav' का उपयोग करते हैं तो हमें प्रदर्शन समस्याओं का सामना नहीं करना पड़ता है? यदि हमें प्रदर्शन के मुद्दों को हल करने के लिए आपको कौन से सुझाव दिए जाएंगे, तो क्या इसे रोकने के लिए कोई तरीका है? – fresher

+0

@PppBeginner हां, ईएवी का उपयोग करने से आने वाली विभिन्न चुनौतियां हो सकती हैं, यही कारण है कि बहुत से लोग इसे एक विरोधी पैटर्न मानते हैं। मैं स्वयं उन विशेष परिस्थितियों को छोड़कर ईएवी का कभी भी उपयोग नहीं करूंगा जहां ईएवी पूरी तरह अनुकूल है। मैंने तर्क दिया है [यहां] (http://stackoverflow.com/questions/11779252/entity-attribute-value-table-design/11972029#11972029) और कहीं और ऑनलाइन उत्पाद कैटलॉग उन अनुप्रयोगों में से एक हैं। उस परिदृश्य में, ईएवी एक प्रदर्शन चिंता नहीं होगी और पूर्ण अर्थपूर्ण डेटा मॉडलिंग लागू होने की तुलना में यह बहुत सरल कोड के साथ काम करेगा। –