एकल मेज विरासत और जहां

Question

मैं एक अजीब डिजाइन समस्या में फंस कर रहा हूँ,

मैं प्रोफाइल मॉडल की एक दो प्रकार पर काम कर रहा हूँ,

• उपयोगकर्ता प्रोफ़ाइल रेल में इसका उपयोग करना (उपयोगकर्ता के अंतर्गत आता है)
• दूसरों कि "बोट्स" के रूप में में साइट को बनाए रखने रहे हैं (किसी का नहीं है)

प्रोफाइल की इन दो प्रकार के विशिष्ट OO व्यवहार में ही है, लेकिन केवल महत्वपूर्ण विशेषताएँ/गुण हैं आम (संख्या में 5-6 बहुत महत्वपूर्ण), अन्य हितों जैसे "हितों आदि" (लगभग 10-15 गुण) बॉट प्रोफाइल

कोडर जिन्होंने इस पर काम किया था, अलग-अलग मॉडल/नियंत्रकों के लिए बनाया गया था बॉट प्रोफाइल/उपयोगकर्ता प्रोफाइल जो हर जगह बहुत सारी अनावश्यकता पैदा करते हैं और साथ ही बनाए रखने के लिए कड़ी मेहनत करते हैं, परीक्षण लिखते हैं। मैं इसे कम करना चाहता था, कम से कम इन सभी अनावश्यक समस्याओं को हल करने के लिए।

किसी एक समाधान

किसी बजाय सुझाव का प्रयोग करें बहुरूपी संघों के रूप में एकल तालिका विरासत का सुझाव दिया।

बेहतर दृष्टिकोण क्या है। हम वास्तव में एसटीआई का उपयोग कब करते हैं?

मेरा स्वयं का विचार था कि एसटीआई का सबसे अच्छा उपयोग किया जाता है जब मॉडल मॉडल के लिए समान होते हैं और वे व्यवहार में भिन्न होते हैं।

विचार मैं क्या कर सकता हूं?

Answer 1

विशेषताएँ एसटीआई को अधिकतर उपयोगी मानते हैं जब गुण समान होते हैं लेकिन व्यवहार भिन्न होता है "सही के बारे में", लेकिन संभवतः थोड़ा सीमित। जब एसटीआई का उपयोग होता है, जैसा कि नाम बताता है, अलग-अलग प्रकार की वस्तुओं के बीच डेटाबेस-शैली संबंधों के बजाय, एक स्पष्ट ओओ-शैली विरासत संबंध।

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

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

एक बात मुझे लगता है कि आपको अपने नियंत्रकों को सूखने से ज्यादा लाभ नहीं दिखाई देगा। मेरे अनुभव में, एसटीआई मॉडल अक्सर इसी तरह के संबंधित नियंत्रकों में अनुवाद नहीं करते हैं। लेकिन यह प्रयोग करने के लिए कुछ और होगा। कभी-कभी जीत होती है, कभी-कभी नहीं होती है।

Answer 2

मैं शायद एसटीआई या कोई विशेष विशेषताओं का उपयोग नहीं करता। आप सबकुछ एक प्रोफाइल को कॉल करने में सक्षम हो सकते हैं और आपको पता होगा कि यह "बॉट" था यदि उसका उपयोगकर्ता शून्य था। आप एसटीआई का उपयोग किये बिना "टाइप" फ़ील्ड भी स्टोर कर सकते हैं।

कुछ बातें एसटीआई का उपयोग करने के लिए अपने निर्णय को प्रभावित करती है:

• है चाहे बॉट-विशिष्ट तर्क
• कितने बॉट (बॉट की छोटी संख्या का मतलब है एसटीआई ठीक है बनाम उपयोगकर्ताओं प्रोफाइल देखते हैं - के बहुत सारे बॉट्स और मैं उन्हें कहीं और स्टोर कर सकता हूं)

एसटीआई से बचने का कारण कभी-कभी यह आपके रास्ते में हो सकता है। उदाहरण के लिए, किसी ऑब्जेक्ट को एक प्रकार से दूसरे में बदलने के लिए काफी परेशान हो सकता है (इस मामले में एक प्रोफाइल में एक बॉट)। कभी-कभी एक साधारण "प्रकार" फ़ील्ड बेहतर होता है।

यह ध्यान देने योग्य है कि यदि आप एसटीआई का उपयोग करते हैं तो शायद आप एक सामान्य बेस क्लास चाहते हैं। तो आप Profile, BotProfile, और UserProfile चाहते हैं। नाम आप पर निर्भर हैं। :)

Answer 3

रेल एसटीआई का एक गोचा - अधिकांश प्लगइन्स (और आगे) पूरी तरह से इसका समर्थन नहीं करते हैं। आप अपने आप को कई आम लोगों को पैच कर पाएंगे।

Answer 4

मैं यह बहुत ही विषय पर एक लेख लिखा है, एसटीआई के साथ काम करने के लिए कुछ सुझाव भी शामिल है:

Single Table Inheritance in Rails

संक्षेप में: वहाँ वस्तुओं के बीच एक स्पष्ट OO शैली विरासत संबंध होने की जरूरत है (के रूप में भाषण द्वारा स्पष्ट रूप से कहा गया है), न केवल कुछ साझा डेटा। यदि कोई प्राकृतिक और स्पष्ट वर्ग पदानुक्रम नहीं है, तो आपके आवेदन के विकास के रूप में एक एसटीआई डिज़ाइन को बनाए रखना मुश्किल हो सकता है।

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

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

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

कुछ और उपयोगी युक्तियों के लिए मेरा आलेख (ऊपर लिंक) देखें।