Question

I would like to create an application that would use the same system as backpack (http://www.backpackit.com) to create different types of pages.

Basically, you can add different elements to a page, and reorder them. Some elements can contains other elements (like an image gallery which contains… images, or lists etc).

I’m not sure how to model that.

I’d like to be able to do something like:

page.elements

without having to retrieve all elements myself

class Page < ActiveRecord::Base
   has_many :texts, :dependent => :destroy
   has_many :titles, :dependent => :destroy

   def elements
       @elts = texts + titles + ...
       #order elts...
   end 
end

So I was thinking about single table inheritance.
I could have a Containers table, and Notes, Galleries, Lists etc could inherit from Containers.
And then, I would have Elements that could be linked to various Containers using polymorphism.

How would you do that? Do you see any fundamental flaws in my approach?

Thanks!

Answer 1

First off, the design is not as efficient as it could be, but whether or not it is fundamentally flawed actually depends on your level of experience:

Case 1: You are relatively new to programming and trying to get started by reverse-engineering and implementing something you can see and understand (backpackit). If this is true then you cannot go wrong by diving in and using the ORM philosophy that database tables can be designed as if they were persisting classes. It will be inefficient, but you’ll learn plenty by not having to worry about the database — yet.

Case 2: You are a veteran programmer (at least one decent app actually being used by people who paid for it) and for some reason are still expressing database design questions in object-oriented terminology. Then you have a fundamental flaw only because there is a good chance you will experience success that will stress the system, at which point the fundamental inefficiency of “table inheritance” will bite you.