2008-12-05 16 views
5

हमारा संगठन हमारे ग्राहकों को विभिन्न प्रकार की सेवाएं प्रदान करता है (उदाहरण के लिए, वेब होस्टिंग, तकनीकी सहायता, कस्टम प्रोग्रामिंग, आदि ...)। हमारी वेबसाइट पर एक पृष्ठ है जो सभी उपलब्ध सेवाओं और उनकी संबंधित कीमतों को सूचीबद्ध करता है। यह स्थैतिक डेटा था, लेकिन मेरा मालिक चाहता है कि यह सब इसके बजाय डेटाबेस से खींचा जाए।डेटाबेस को मॉडलिंग करते समय आप "विशेष-केस" डेटा को कैसे प्रबंधित करते हैं?

लगभग 100 सेवाएं सूचीबद्ध हैं। उनमें से केवल दो में "कीमत" (विशेष रूप से, तार "आईएसए" और "लागत + 8%" के लिए एक गैर संख्यात्मक मूल्य है - मुझे वास्तव में पता नहीं है कि उनका क्या मतलब है, इसलिए नहीं मुझसे पूछें)।

मैं इन दो लिस्टिंग के कारण "कीमत" कॉलम को वर्चर बनाने से नफरत करता हूं। मेरा वर्तमान दृष्टिकोण एक विशेष "price_display" फ़ील्ड बनाना है, जो या तो खाली है या मूल्य के स्थान पर प्रदर्शित करने के लिए टेक्स्ट शामिल है। यह समाधान एक गंदे हैक की तरह बहुत अधिक महसूस करता है (हालांकि यह अनिवार्य रूप से प्रश्नों को जटिल करेगा), तो क्या कोई बेहतर समाधान है?

उत्तर

4

मान लें कि यह कॉलम ग्राहक पर प्रदर्शित मूल्य है जिसमें कुछ भी शामिल हो सकता है।

यदि आप इसे संख्यात्मक कॉलम बनाने का प्रयास करते हैं तो आप दुःख को आमंत्रित करेंगे। आप पहले से ही दो गैर-अनुरूप मूल्यों के साथ संघर्ष कर रहे हैं, और कल आपके मालिक को और अधिक चाहिए ...

  • आवेदन पर मूल्य!
  • आज के लिए हमें कॉल करें !!

आपको यह विचार मिलता है।

यदि आपको वास्तव में एक संख्यात्मक कॉलम की आवश्यकता है तो इसे आंतरिकप्रिस या कुछ कहें, और इसके बजाय उस कॉलम पर अपनी संख्यात्मक बाधाएं डालें।

+0

आप सही हैं। हमारा मालिक अन्य सेवाओं के लिए "कीमत" में कुछ ऐसा करना चाहता है। साथ ही, जहां तक ​​मुझे पता है कि इस डेटा के लिए कोई व्यावसायिक तर्क नहीं होगा। इसे वर्चर बनाना सबसे अच्छा तरीका हो सकता है। धन्यवाद। – Cybis

+0

डॉन।जैसे ही मैंने समाप्त किया, मेरे मालिक कहते हैं, "अब हम चरण 2 पर जाते हैं - एक 'मूल्य अनुमानक' बनाएं जो चयनित सेवाओं की कुल लागत को बढ़ाएगा"। मुझे लगता है कि मैं "display_price" कॉलम का उपयोग करने के लिए वापस जाऊंगा। – Cybis

+1

:-) बॉस आमतौर पर इसे दोनों तरीकों से चाहते हैं। –

1

शायद मुख्य तालिका में 'प्रकार' संकेतक का उपयोग करें, जिसमें एक बाल तालिका संख्यात्मक मूल्य और चरित्र मूल्यों के साथ किसी अन्य को अनुमति दे। इन्हें एक टेबल में जोड़ा जा सकता है, लेकिन मैं आमतौर पर इससे बचता हूं। यदि आप कभी भी खरीदी गई मात्रा पर आधार का आधार बनाना चाहते हैं तो आप मात्रा के साथ एक मध्यवर्ती लिंक तालिका का भी उपयोग कर सकते हैं।

+0

RickH के जवाब को देखते हुए, मैं वास्तव में अपने सामान्य मामले का एक लचीला कार्यान्वयन के रूप में अपने समाधान 5 पसंद है। यह, इंटरमीडिएट टेबल के साथ संयुक्त है जो मैंने कर गणना के लिए उपयोग किया है, जो एक समान मामला है। – Nerdfest

1

विकल्पों की बहुत सारे:

  1. सभी मूल्यों संग्रहीत
  2. कीमतें varchars के रूप में संख्यानुसार संग्रहीत और अतिरिक्त price_display क्षेत्र है कि नंबर अगर आबादी
  3. कीमतें मैन्युअल आबादी वाले प्रदर्शन प्रयोजनों के लिए numberically संग्रहीत और अतिरिक्त price_display क्षेत्र को ओवरराइड करता है या ट्रिगर पर जब संख्यात्मक मूल्य अपडेट किया जाता है (डेटा का डुप्लिकेशंस और यह सिंक से बाहर हो सकता है - yuk)
  4. विशेष स्थिति नकारात्मक कीमतों को स्टोर करें जो विशेष परिस्थितियों (बस युक !!)
  5. वर्चर मूल्य, उपसर्ग कुंजी फ़ील्ड उपलब्ध उपसर्गों ('लागत +', ...) की तालिका में प्रत्यय कुंजी फ़ील्ड, उपलब्ध प्रत्यय की तालिका में प्रत्यय कुंजी फ़ील्ड, मूल्य में मूल्य के लिए प्रकारों की सूची में फ़ील्ड कुंजी टाइप करें (' $ ','% ',' विवरण ')। उपयोगी अगर आपको भविष्य में कीमतों के खिलाफ जटिल प्रश्न लिखना होगा।

मैं शायद व्यावहारिक समाधान के रूप में 2 के लिए जाऊंगा, और 5 के विस्तार के लिए यदि मुझे सामान्य मूल्य निर्धारण प्रणाली के लिए कुछ सामान्य की आवश्यकता है।

2

अपने आप से पूछें ...

क्या मैं इन मानों को जोड़ रहा हूं? क्या मैं कीमत से छंटनी करूँगा? क्या मुझे अन्य मुद्रा मूल्यों में कनवर्ट करने की आवश्यकता होगी?

या

मैं सिर्फ एक वेब पेज पर यह मान प्रदर्शित होगा?

यदि यह सिर्फ एक कपड़े धोने की सूची है और गणना के लिए इस्तेमाल नहीं आसान समाधान एक स्ट्रिंग (varchar) के रूप में कीमत स्टोर करने के लिए है।

1

यह आपका डाटा मॉडल की हद तक है, तो एक varchar क्षेत्र ठीक है। आपकी सामान्य कीमतें - दशमलव जितनी हो सकती हैं - वैसे भी गणना के लिए बेकार हैं। "डेटा ट्रांसफर" के लिए $ 10/GB और "डोमेन होस्टिंग" के लिए $ 25/माह की तुलना कैसे करते हैं?

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

बेशक

- आप कीमत एक विशेष परियोजना के लिए भुगतान एक विशेष ग्राहक के भंडारण कर रहे हैं, या यह पता लगाने की क्या एक विशेष ग्राहक को चार्ज करने की कोशिश कर रहा है - तो आप एक अलग (और अधिक जटिल) डोमेन की है। और आपको इसका समर्थन करने के लिए एक अलग मॉडल की आवश्यकता होगी।

1

कि कम से कम वैकल्पिक कीमतों में से एक में एक नंबर शामिल किया है, जो एक मूल्य स्तम्भ, मूल्य प्रकार के बारे में? सामान्य प्रविष्टियां डॉलर के मूल्य के लिए एक संख्या हो सकती हैं और 'डॉलर' टाइप कर सकती हैं, और दूसरा 8 और 'प्रतिशत ओवरकोस्ट' और शून्य और 'आईएसए' (मूल्य और मूल्य टाइप कॉलम के लिए) हो सकता है।

आप शायद मान्य और PriceTypeID करने के लिए यदि आप इस मार्ग जाना एक PriceType तालिका होनी चाहिए।

यह अनुमति होगी मूल्य निर्धारण के अन्य प्रकार (इकाई मूल्य निर्धारण, विदेशी currancy) भविष्य में जोड़ा जा करने के लिए आप एक नंबर देते हैं, और भी आसान पता करने के लिए किस प्रकार का मूल्य निर्धारण आप के साथ काम कर रहे हैं बनाने के ..

4

जब मैं अतीत मैं प्रयोग किया जाता में बात की इस तरह करना पड़ा है:

Price Unit Display 
10.00 item null 
100.00 box null 
null null "Call for Pricing" 

मूल्य होगा दशमलव डेटाप्रकार (किसी भी सटीक सांख्यिक, नाव या असली नहीं), इकाई और प्रदर्शन स्ट्रिंग डेटा प्रकार किसी प्रकार होगा ।

फिर केस प्रति स्टेटमेंट या मूल्य के साथ मूल्य प्रदर्शित करने के लिए केस स्टेटमेंट का उपयोग किया। डिस्प्ले कॉलम पर एक बाधा डालें या ट्रिगर करें ताकि जब तक कीमत शून्य न हो तब तक यह शून्य होनी चाहिए। यदि कीमत शून्य नहीं है तो एक बाधा या ट्रिगर को इकाई में मूल्य की भी आवश्यकता होनी चाहिए।

इस तरह आप एक आदेश जहां संभव हो और जब कीमत निर्दिष्ट नहीं है उन्हें बाहर छोड़ लेकिन दोनों प्रदर्शित के लिए कीमतों calcuate कर सकते हैं। मैं यह सुनिश्चित करने के लिए एक बसता नियम भी डालूंगा कि जब तक मूल्य निर्धारण के लिए कॉल का समाधान नहीं हो जाता तब तक कुल को कुल नहीं किया जा सकता था (जिसे आपको ऑर्डर विवरण में विशेष मूल्य डालने का तरीका भी होगा, बस खींचने के बजाय मूल्य तालिका)।

+0

यह प्रोजेक्ट 7 महीने पहले था, एक जगह पर मैं अब काम नहीं करता हूं। धन्यवाद हालांकि, यह भविष्य में उपयोगी होगा। – Cybis

संबंधित मुद्दे

 संबंधित मुद्दे