5

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

हम निम्नलिखित पैटर्न हमारे आवेदन में एक बहुत कुछ है:

class Project < ActiveRecord::Base 
    has_many :graph_settings 
end 

class GraphType < ActiveRecord::Base 
    has_many :graph_settings 
    #graph type specific settings (units, labels, etc) stored in DB and very infrequently updated. 
end 

class GraphSetting < ActiveRecord::Base 
    belongs_to :graph_type 
    belongs_to :project 
    # Project implementation of graph type specific settings (y_min, y_max) also stored in db. 
end 

यह भी देखा गया, सहायकों में और GraphSetting मॉडल अपने आप में सशर्त, की एक टन का परिणाम है। इनमें से कोई भी अच्छा नहीं है।

एक साधारण refactor जहां हम और अधिक इस तरह की एक संरचना का उपयोग के पक्ष में GraphType से छुटकारा पाने:

class Graph < ActiveRecord::Base 
    belongs_to :project 
    # Generic methods and settings 
end 

class SpecificGraph < Graph 
    # Default methods and settings hard coded 
    # Project implementation specific details stored in db. 
end 

अब यह मेरे लिए एकदम सही समझ में आता है, परीक्षण को आसान बनाता है, सशर्त, निकाल देता है, और बाद में अंतर्राष्ट्रीयकरण आसान बना देता है। हालांकि हमारे पास केवल 15 से 30 ग्राफ हैं।

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

क्या 200 एसटीआई कक्षाएं कई हैं? क्या कोई और पैटर्न है जिसे हमें देखना चाहिए?

किसी भी ज्ञान के लिए धन्यवाद और मैं किसी भी प्रश्न का उत्तर दूंगा।

उत्तर

4

यदि मतभेद सिर्फ वर्ग के व्यवहार में हैं, तो मुझे लगता है कि यह कोई समस्या नहीं होनी चाहिए, और यह एसटीआई के लिए एक अच्छा उम्मीदवार है। (आपको याद है, मैंने कभी भी इतने सारे सबक्लास के साथ यह कोशिश नहीं की है।)

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

class SpecificGraph < Graph 
    include SpecificGraphDetail::MTI 
end 

class SpecificGraphDetail < ActiveRecord::Base 
    module MTI 
    def self.included(base) 
     base.class_eval do 
     has_one :specific_graph_detail, :foreign_key => 'graph_id', :dependent => :destroy 
     delegate :extra_column, :extra_column=, :to => :specific_graph_detail 
     end 
    end 
    end 
end 

प्रतिनिधिमंडल साधन:

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

आपको उन परिस्थितियों का व्यापार करना होगा जहां आपको मास्टर टेबल में अतिरिक्त कॉलम के खिलाफ इन अतिरिक्त विवरण तालिकाओं में शामिल होने की आवश्यकता है। इससे तय होगा कि उपरोक्त मेरे समाधान जैसे एसटीआई या संबंधित तालिकाओं का उपयोग करके समाधान का उपयोग करना है या नहीं।

+0

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

+0

http://stackoverflow.com/questions/1634668/multiple-table-inheritance-vs-single-table-inheritance-in-ruby-on-rails/1634734#1634734 में एक और समान दृष्टिकोण है –