Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You are indeed missing something obvious. Do you know what STI stands for? <strong>Single Table</strong> Inheritence. You are making several tables and then trying to use STI.</p> <p>You should only use STI if your tables identical or very similar (maybe 1 field of difference). It is primarily used when you want to subclass and then provide methods to differentiate behaviour. For example, maybe all users share the same attributes but some of them are admins. You can have a <code>type</code> field in your users table, and then you might have something like this:</p> <pre><code>class Admin &lt; User def admin? true end end class NormalUser &lt; User def admin? false end end </code></pre> <p>(this is obviously a very simple example and probably wouldn't warrant STI on it's own).</p> <p>As far as abstract classes go, that is a good decision if you have several tables that should all inherit behaviour from a super class. It seems like it might make sense in your case; however, it is important to note that abstract classes do not have tables. The whole point of declaring <code>abstract_class</code> as true is so that ActiveRecord won't get confused when trying to look for a table that doesn't exist. Without it, ActiveRecord will assume you are using STI and try to look for a Questions table. In your case, you do have a question table, so declaring it as an abstract class doesn't really make sense.</p> <p>One other thing, you ask "Should I be using the module approach instead of inheritance?". Using modules is actually a form of inheritence in Ruby. When you include a module, it is inserted in the classes ancestor chain just like a super class would be (modules are inserted BEFORE super classes however). I do think that some form of inheritance is the correct approach. In this case, because they are both types of questions, making an abstract Question superclass makes sense to me. Because the questions don't share many of their attributes, storing them in separate tables is the best solution in my opinion. STI is not really a good practice when you have several differing fields, because it leads to a lot of <code>null</code> in your database.</p> <p>And to be clear about modules, I think that it is best done when several otherwise unrelated models share some form of common behaviour. One example that I've used multiple times is the idea of a <code>Commentable</code> module (using ActiveSupport::Concern). Just because several models can be commented on doesn't necessarily warrant a superclass because the models are not related - they do not really descend from some sort of parent object. This is where a module makes sense. In your case, a superclass makes sense because both of your models are typed of questions, so it seems appropriate that they both descend from a generic <code>Question</code> base class.</p>
    singulars
    1. This table or related slice is empty.
    1. POCan't get an STI/ActiveRecord model to do what I expect
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USLogan Serman
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCan't get an STI/ActiveRecord model to do what I expect
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSingle table, right. I think I've been up too late. Thank you Logan! So, sounds like inheritance is good and I've got two possibilities: 1) make Question abstract, and give each subclass its own table; or 2) make Question non-abstract and use STI (correctly). I like option 1, but from playing with it just now it looks like I can't call 'survey.questions' anymore to get all of my subclassed questions -- correct? Should I just write my own survey.questions method?
      singulars
      1. PO
      1. USAeonaut
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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