5

Tôi đang làm việc trên một ứng dụng Rails rất lớn. Ban đầu chúng tôi không sử dụng nhiều thừa kế, nhưng chúng tôi đã có một số kinh nghiệm mở mắt từ một nhà tư vấn và đang tìm cách tái cấu trúc một số mô hình của chúng tôi.Có bao nhiêu lớp học quá nhiều? Rails STI

Chúng tôi có mẫu sau rất nhiều trong ứng dụng của chúng tôi:

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 

này cũng dẫn đến một tấn điều kiện trong quan điểm, những người giúp đỡ và trong mô hình GraphSetting riêng của mình. Không ai trong số này là tốt.

Một cấu trúc lại đơn giản mà chúng ta thoát khỏi GraphType ủng hộ của việc sử dụng một cấu trúc như thế này:

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 

Bây giờ điều này làm cho cảm giác hoàn hảo với tôi, giúp giảm bớt thử nghiệm, loại bỏ điều kiện, và làm cho quốc tế hóa sau dễ dàng hơn. Tuy nhiên, chúng tôi chỉ có 15 đến 30 biểu đồ.

Chúng tôi có một mô hình rất giống nhau (phức tạp để sử dụng làm ví dụ) với gần 100 loại 'khác nhau' và có khả năng tăng gấp đôi. Họ sẽ có tất cả các mối quan hệ và phương pháp mà họ thừa kế, một số sẽ cần phải ghi đè lên nhiều phương pháp hơn những phương pháp khác. Nó có vẻ giống như sử dụng hoàn hảo, nhưng mà nhiều người dường như rất nhiều.

Có 200 lớp STI cho nhiều người không? Có một mô hình khác mà chúng ta nên xem xét không?

Cảm ơn mọi sự khôn ngoan và tôi sẽ trả lời bất kỳ câu hỏi nào.

Trả lời

4

Nếu sự khác biệt chỉ là trong hành vi của lớp học, thì tôi cho rằng đó không phải là vấn đề, và đây là một ứng cử viên tốt cho STI. Tuy nhiên, nếu 200 lớp STI của bạn có một số thuộc tính duy nhất, bạn sẽ cần nhiều cột cơ sở dữ liệu bổ sung trong bảng chính sẽ là NULL , 99,5% thời gian. Điều này có thể rất kém hiệu quả.

Để tạo một cái gì đó như "bảng thừa kế nhiều", những gì tôi đã làm trước đó với thành công là sử dụng một chút lập trình meta để kết hợp các bảng khác cho các chi tiết duy nhất cho mỗi lớp:

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 

Các phương tiện đoàn bạn có thể truy cập vào các trường chi tiết được liên kết như thể chúng trực tiếp trên mô hình thay vì đi qua liên kết specific_graph_detail và cho tất cả các mục đích và mục đích, "trông" như thế này chỉ là các cột bổ sung.

Bạn phải trao đổi các tình huống mà bạn cần tham gia các bảng chi tiết bổ sung này để chỉ có các cột bổ sung trong bảng chính. Điều đó sẽ quyết định có sử dụng STI hay một giải pháp sử dụng các bảng được liên kết, chẳng hạn như giải pháp của tôi ở trên.

+0

Cảm ơn bạn đã trả lời. Tại thời điểm này tôi không nghĩ rằng chúng tôi sẽ có nhiều (nếu có) null giá trị trong cơ sở dữ liệu, như các thuộc tính là như nhau, chỉ các giá trị và phương pháp sẽ thay đổi. (Ví dụ như cách nó trả về dữ liệu cho đồ thị để vẽ). Nếu chúng tôi kết thúc với các trường rỗng (có thể không phải là trường hợp cụ thể này, nhưng các trường hợp tương tự khác), tôi chắc chắn sẽ ghi nhớ điều này. –

+0

Có một cách tiếp cận tương tự khác trong http://stackoverflow.com/questions/1634668/multiple-table-inheritance-vs-single-table-inheritance-in-ruby-on-rails/1634734#1634734 –

Các vấn đề liên quan