From: Mat Schaffer <schapht@...>
Date: 2006-12-28T13:23:56+09:00
Subject: Re: Modified Single Table Inheritance

On Dec 27, 2006, at 8:19 PM, Ryan Glover wrote:
> All the objects are the same thing, so to speak.  As a silly  
> example of
> what I am trying to do, let's say that each user an array named fruit.
> There are many types of fruit and each have their own unique  
> attributes
> (# of grapes, fuzziness index of peach, banana radius) but they are  
> all
> fruit.  My program is just like this, except I have hundreds of fruit.
> Perhaps even a thousand.  Ideally I would like to be able to add more
> fruit as the program evolves just by adding a new fruit subclass and a
> new fruit view.

Well, I'm guessing fruit is just an example.  But I think you could  
still group the fruits into subcategories or something to that effect  
and end up with reasonable inheritance. For example, berries  
(strawberry, raspberry) , pitted fruits (peach, concord grape), not  
sure what you'd call a banana but I'd bet an encyclopedia would have  
some info.  But I think you get the idea.  To get the specific kind  
of fruit, you could just use a type field and get single table  
inheritance on the subcategory.

It'll depend on your data model.  But I'm inclined to agree with the  
rest of group that there are either relationships or duck-typing  
advantages that you're not utilizing.

And David has a point of schemas that include things like float1,  
etc... do often show up on the daily WTF.  That's might be reason  
enough to stay away.

Thinking another way, what about having a fruit table and a trait  
table.  The trait table could reference a large number of  
trait_types.  The trait table would reference a fruit, a trait_type  
and a value.  You could probably get away with just 3 or 4 value  
columns in the trait table.  Just a thought.
-Mat