Best Practice for Model Design in Ruby on Rails

Question

The RoR tutorials posit one model per table for the ORM to work. My DB schema has some 70 tables divided conceptually into 5 groups of functionality (eg, any given table lives in one and only one functional group, and relations between tables of different groups are minimised.) So: should I design a model per conceptual group, or should I simply have 70 Rails models and leave the grouping 'conceptual'? Thanks!

Answer 1

Most likely, you should have 70 models. You could namespace the models to have 5 namespaces, one for each group, but that can be more trouble than it's worth. More likely, you have some common functionality throughout each group. In that case, I'd make a module for each group containing its behavior, and include that in each relevant model. Even if there's no shared functionality, doing this can let you quickly query a model for its conceptual group.

Answer 2

You should definitely use one model per table in order to take advantage of all the ActiveRecord magic.

But you could also group your models together into namespaces using modules and sub-directories, in order to avoid having to manage 70 files in your models directory.

For example, you could have:

app/models/admin/user.rb
app/models/admin/group.rb

for models Admin::User and Admin::Group, and

app/models/publishing/article.rb
app/models/publishing/comment.rb

for Publishing::Article and Publishing::Comment

And so forth...

Answer 3

There may be a small number of cases where you can use the Rails standard single-table-inheritance model. Perhaps all of the classes in one particular functional grouping have the same fields (or nearly all the same). In that case, take advantage of the DRYness STI offers. When it doesn't make sense, though, use class-per-table.

In the class-per-table version, you can't easily pull common functionality into a base class. Instead, pull it into a module. A hierarchy like the following might prove useful:

app/models/admin/base.rb - module Admin::Base, included by all other Admin::xxx
app/models/admin/user.rb - class Admin::User, includes Admin::Base
app/models/admin/group.rb - class Admin::Group, includes Admin::Base

Answer 4

Without knowing more details about the nature of the seventy tables and their conceptual relations it isn't really possible to give a good answer. Are these legacy tables or have you designed this from scratch?

Are the tables related by some kind of inheritance pattern or could they be? Rails can do a limited form of inheritance. Look up Single Table Inheritance (STI).

Personally, I would put a lot of effort into avoiding working with seventy tables simply because that is an awful lot of work - seventy Models & Controllers and their 4+ views, helpers, layouts, and tests not to mention the memory load issue of keeping the design in ind. Unless of course I was getting paid by the hour and well enough to compensate for the repetition.

Answer 5

It's already mentioned, it's hard to give decent advice without knowing your database schema etc, however, I would lean towards creating the 70+ models, (one for each of your tables.)

You may be able to get away with ditching some model, but for the cost (negliable) you may as well have them there.

You don't need to create a controller + views for each model (as answerd by srboisvert). You only need a controller for each resource (which I would expect to be a lot less than 70 - probably only 10 or 15 or so judging by your description).

Answer 6

Before jumping in a making 70 models, please consider this question to help you decide:

Would each of your tables be considered an "object" for example a "cars" table or are some of the tables holding only relationship information, all foreign key columns for example?

In Rails only the "object" tables become models! (With some exception for specific types of associations) So it is very likely that if you have only 5 groups of functionality, you might not have 70 models. Also, if the groups of functionality you mentioned are vastly different, they may even be best suited in their own app.

Answer 7

I cover this in one of my large apps by just making sure that the tables/models are conceptually grouped by name (with almost 1:1 table-model relationship). Example:

events
event_types
event_groups
event_attendees
etc...

That way when I'm using TextMate or whatever, the model files are nicely grouped together by the alpha sort. I have 80 models in this app, and it works well enough to keep things organised.