views:

95

answers:

1

OK, so I've been toying with different ways of organizing my Rails 3 apps regarding STI and Polymorphic Associations. I was trying to find a way that is both easy to code, and easy to use, and has the highest chance of being the most compatible with any future changes. After alot of reading a lot of optionated (and often lacking and poorly written) articles, I've come to some conclusions of my own.

First, it seems that using STI is the safest bet, in terms of being easy to code, easy to read and use, and easy to work with any future changes without too much re-writing. The only legitimate downside I can see is that in your DB there will be "holes" in the data. Some ppl think that this is a bad thing. But, IMHO, if this is the only downside and the upshot is making the rest of your life a hell of a lot easier, then WHO CARES?

Second, it seems that Polymorphic Associations really only work nicely in certain situations, definitely not ALL situations. Moreover, it seems that any situation where you COULD use Polymorphic Associations, you could also just use STI (and not the other way around ). So why bother with Polymorphic Associations at all? Just to get those pesky "holes" out of your DB? But then you are adding duplicated fields and extra tables that look an awful lot alike, not to mention multiple sets of controllers and models and views etc.

Third, even if you do identify a proper time to use Polymorphic Associations, and properly implement it, things could change and you would find yourself having to rip out the Polymorphic stuff and end up implementing STI anyways. I'm not seeing a time when this would happen the other way around. STI seems to play nice with any setup, whereas Polymorphic Associations seem to need things to be "just so" in order to work as advertised.

Now, I'm not the smartest guy, so these could be wrong-headed and/or short-sighted observations - Please let me know if you think I am wrong, and try to provide some good evidence to support your case!

A: 

If I was to take your argument to its furthest conclusion I would get something like: why even bother with having multiple database tables? Just use one table and STI to store all your data.

Additionally, consider a bookstore application with authors, publishers, books and users. Imagine that there is an option for a user to subscribe to email notifications for changes to any of authors, books, or publishers. To do this, one might create a notifications table. This table would want to have a polymorphic association to any of the objects that can be followed. How would you structure that in a cleaner way with STI?

Anthony Chivetta
Obviously you wouldnt put everything in 1 table. I think you may be right when the objects in question are totally unrelated, this would make sense. But, lets say we were just talking about Authors and Publishers, you could just make both of them inherit from "Person", or whatever, and avoid Polymorphic Associations. You might even be able to use an Observer somehow and avoid both.
Buddy