small medium large xlarge

31 Aug 2008, 17:12
defucius tai (3 posts)

In the single table inheritance example, would it possible for the employee to also be a customer? If not, how would this case be handled?

A similar situation would be people, teacher, and student, where a teacher could also be a student. Would it be possible to use STI in this situation? or something else?


03 Sep 2008, 04:24
defucius tai (3 posts)

Since no one has offered any comments, let me add a little more to the question. I’ve gotten a piece of advice in reconsidering what value STI adds in both of these cases, besides elegance in style.

I can’t see the value clearly beyond elegance. Given the flat underlying table of STI, is it more straightforward just to use a flat table, and forget about STI?

Somehow, I feel like there must a good reason for the existance of STI. Maybe it is just not suited for the examples cited here?

insights, please.

22 Sep 2008, 02:53
Mikhail V. Shokhirev (a.k.a. Mike Shock) (19 posts)

(As my son Lev said: “every class hierarchy should be disigned according to the certain situation”.) The example of the class tree in chapter 18 (Employee < Person, Customer < Person) expresses the idea of INHERITANCE: “ALL employess and ALL customers are people”.

In this hierarchy the notion of an “employee also being a customer” can’t be expressed only by inheritance: it’s not quite natural for an Employee to be a subcluss of a Customer or vice versa. And introducing a special attribute or method to distinguish an employee form customer is certainly an ugly decision.

In many situations the realization of inheritance in Rails (STI) helps us to elegantly represent a group of closely related classes with common attributes in the parent class and specific attributes in child classes. (And this kind of inheritance is NOT MULTIPLE: the parent class is always ONE.)

But there are many situations where inter-relationships between the classes express the idea of ASSOCIATION, for example: SOME persons may study as students and SOME (or none) of them may work as teachers. (Persons that can work as employees and those of them that may have contracts as customers are 2 subsets of People that can overlap just partially.) Such relationships should be better expressed as polymorphic associations or, maybe, has_many :through relationship.

You must be logged in to comment