StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Have you considered the mixed model approach?</p> <p>Where you use single table inheritance for your core notification fields. Then offload all the unique items to specific tables/models in a belongs to/has one relationship with your notification subclasses.</p> <p>It's a little more overhead to set up, but works out to be pretty DRY, once all the classes and tables are defined. Seems like a pretty efficient way to store things. With eager loading you shouldn't be causing too much additional strain on the database.</p> <p>For the purposes of this example, lets assume that Emails have no unique details. Here's how it maps out.</p> <pre><code>class Notification < ActiveRecord::Base # common methods/validations/associations ... def self.relate_to_details class_eval <<-EOF has_one :details, :class_name => "#{self.name}Detail" accepts_nested_attributes_for :details default_scope -> { includes(:details) } EOF end end class SMS < Notification relate_to_details # sms specific methods ... end class Twitter < Notification relate_to_details # twitter specific methods ... end class Email < Notification # email specific methods ... end class SMSDetail < ActiveRecord::Base belongs_to :SMS, :class_name => "SMS" # sms specific validations ... end class TwiterDetail < ActiveRecord::Base belongs_to :twitter # twitter specific validations ... end </code></pre> <p>Each of the detail tables will contain a notification ID and only columns that form of communication needs that isn't included in the notifications table. Although it would mean an extra method call to get media specific information. </p> <blockquote> <p>This is great to know but do you think it's necessary? </p> </blockquote> <p>Very few things are necessary in terms of design. As CPU and storage space drop in cost so do those necessary design concepts. I proposed this scheme because it provides the best of both STI and MTI, and removes a few of their weaknesses.</p> <p>As far as advantages go:</p> <p>This scheme provides the consistency of STI. With tables that do not need to be recreated. The linked table gets around dozens of columns in that are empty in 75% of your rows. You also get the easy subclass creation. Where you only need to create a matching Details table if your new type isn't completely covered by the basic notification fields. It also keeps iterating over all Notifications simple.</p> <p>From MTI, you get the storage savings and the ease of customization in meeting a class's needs without needing to redefine the same columns for each new notification type. Only the unique ones.</p> <p>However this scheme also carries over the major flaw with STI. The table is going to replace 4. Which can start causing slowdown once it gets huge. </p> <p>The short answer is, no this approach is not necessary. I see it as the most DRY way to handle the problem efficiently. In the very short run STI is the way to do it. In the very long run MTI is the way to go, but we're talking about the point where you hit millions of notifications. This approach is some nice middle ground that is easily extensible.</p> <h2>Detailed gem</h2> <p>I've built a gem over your solution: <a href="https://github.com/czaks/detailed" rel="nofollow noreferrer">https://github.com/czaks/detailed</a>. Using it you can simplify your Notification class to:</p> <pre><code>class Notification < ActiveRecord::Base include Detailed end </code></pre> <p>The rest goes the previous way.</p> <p>As an added bonus, you can now access (read, write, relate) the subclass-specific attributes directly: <code>notification.phone_number</code>, without resorting to: <code>notification.details.phone_number</code>. You can also write all code in the main classes and subclasses, leaving the Details model empty. You will also be able to do less queries (in the above example 4 instead of N+1) on large datasets using <code>Notification.all_with_details</code> instead of the regular <code>Notification.all</code>.</p> <p>Be aware, that at the current time this gem isn't tested very well, though it works in my usecase.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload