कस्टम फ़ील्ड्स और डेटा प्रकारों के लिए डिज़ाइन पैटर्न / रणनीतियाँ

12

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

design-patterns database-design

— GSto
स्रोत

6

उपयोगकर्ता-परिभाषित क्षेत्रों के लिए एक डेटाबेस डिजाइन करने के बारे में इस सवाल के

— राहेल

ध्यान दें: ओरेकल सभी के पैंट उतारने के आस-पास जा रहा है जो इसे एक विशेष रूप से लागू करता है (जो मैं समझता हूं, सामान्य तरीके से)। मैं उस पर भी एक नज़र रखना चाहते हैं।

— स्टीवन एवर्स

6

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

http://martinfowler.com/apsupp/properties.pdf

— डॉक्टर ब्राउन
स्रोत

4

EAVमॉडल सामान्य रूप से के रूप में आप का वर्णन असंरचित स्कीमा के लिए प्रयोग किया जाता है।

यह प्रदर्शन और इस तरह के गतिशील गुणों को एक तदर्थ तरीके से क्वेरी करने की क्षमता से ग्रस्त है ... और जैसा कि कई लोगों द्वारा एक विरोधी पैटर्न माना जाता है।

अन्य दृष्टिकोण ऐसे गुणों को धारण करने के लिए XML या जोंस जैसे गतिशील प्रारूप का उपयोग करने के लिए हैं, संभवतः प्रत्येक संपत्ति के लिए खोज में मदद करने के लिए समर्पित भंडारण के साथ।

— Oded
स्रोत

मैंने EAV के विकल्प के रूप में दस्तावेज़-उन्मुख डेटाबेस का उपयोग करने वाले लोगों के बारे में भी सुना है, लेकिन इस तरह के दृष्टिकोण के साथ कोई व्यक्तिगत अनुभव नहीं है।

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner - यह वही है जो मैं इशारा कर रहा था, लेकिन खुद के रूप में, कोई व्यक्तिगत अनुभव नहीं।

— Oded

4

@Oded वर्णन करता है कि EAV तालिका के लिए लत में, लोग इस प्रकार की जानकारी के लिए nosql datbase का उपयोग करते हैं। याद रखें कि ऐसा कोई कारण नहीं है कि आपका एप्लिकेशन उन रिलेशंस के लिए रिलेशनल डेटाबेस का उपयोग नहीं कर सकता है जो रिलेशनल मॉडल के साथ समझ में आता है और जो जानकारी नहीं है उसके लिए एक नॉस्कल डेटाबेस।

तीसरी संभावना यह है कि ग्राहक द्वारा जोड़े गए क्षेत्रों (Customerfield1, customerfield2, आदि) के लिए कई कॉलम जोड़ते हैं और फिर ग्राहक को परिभाषित करते हैं कि उनका क्या मतलब है। यह केवल आपके द्वारा जोड़े जाने वाले ग्राहक comnfiguarble फ़ील्ड की संख्या के लिए काम करता है, इसलिए यह ठीक है यदि आप केवल उम्मीद करते हैं कि उन्हें दो या तीन की आवश्यकता होगी, लेकिन आप सैकड़ों की आवश्यकता होने पर बिल्कुल भी काम नहीं करेंगे।

— HLGEM
स्रोत

1

आपके पास पहला आवेदन नहीं होगा जिसमें एक तालिका थी: UDF1, UDF2, UDF3 ... अन्य सुझाव (EVA या NoSQL) बहुत बेहतर हैं।

RDBMS ( SQL Server यह प्रदान करता है ) के आधार पर , आप सामान्यीकरण से बाहर निकल सकते हैं और एक फ़ील्ड है जो डेटा को XML प्रारूप या सिर्फ सादे पाठ में रखता है। आपको इसे प्रबंधित करने के लिए कोड पर निर्भर रहना होगा।

— JeffO
स्रोत