Comments on: Ruby on Rails Polymorphic Association Benchmarks http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/ News and updates from the people at SmartLogic Solutions Thu, 04 Dec 2008 18:33:55 +0000 http://wordpress.org/?v=2.7-bleeding By: Xavier Shay http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-70 Xavier Shay Sun, 15 Jun 2008 02:02:40 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-70 You likely can use the SET datatype - it basically gives you strings but stores them internally as integers. We've hacked the enum-column plugin to support it for mysql - haven't tried with polymorphics yet, but it works fine with STI, which I presume is similar code. It's too ugly for public consumption at the moment but if you're interested drop me a line. You likely can use the SET datatype - it basically gives you strings but stores them internally as integers. We’ve hacked the enum-column plugin to support it for mysql - haven’t tried with polymorphics yet, but it works fine with STI, which I presume is similar code. It’s too ugly for public consumption at the moment but if you’re interested drop me a line.

]]> By: Nick Gauthier http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-69 Nick Gauthier Sat, 14 Jun 2008 22:32:27 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-69 @David: Right, the int key vs string key is a small percentage. 57 vs 51 in your case. @Dan (and everyone): Please add tests to the code base, we'll all benefit from more benchmarks! -Nick @David: Right, the int key vs string key is a small percentage. 57 vs 51 in your case.

@Dan (and everyone): Please add tests to the code base, we’ll all benefit from more benchmarks!

-Nick

]]> By: David Dai http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-68 David Dai Sat, 14 Jun 2008 21:23:11 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-68 To clarify, I mean Integer key VS string key. Not indexed VS non-indexed. To clarify, I mean Integer key VS string key. Not indexed VS non-indexed.

]]> By: David Dai http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-67 David Dai Sat, 14 Jun 2008 21:15:06 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-67 I ran it on 10,000 rows on my mac book pro 2.6GHz Core2 Duo, 4GB RAM with MySQL: http://pastie.org/215147 I don't see much of a difference. I ran it on 10,000 rows on my mac book pro 2.6GHz Core2 Duo, 4GB RAM with MySQL:

http://pastie.org/215147

I don’t see much of a difference.

]]> By: Dan Kubb http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-66 Dan Kubb Sat, 14 Jun 2008 19:03:23 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-66 Another suggestion: you should benchmark this approach against the old-school approach of using an explicit join table between the two tables, since it's the classic alternative to polymorphic associations and would provide a nice baseline. I personally am still inclined to use a join table rather than polymorphic associations. It's very rare that I have something that needs to be "promiscuous" enough that I won't be able to know up-front what needs to be joined to what. I tend to prefer it because I can add constraints to the join table to ensure one side is unique, for example. It also leaves room open in case I need to add other information to the relationship (as I often do) such as the time the relationship was created/updated, etc. Another suggestion: you should benchmark this approach against the old-school approach of using an explicit join table between the two tables, since it’s the classic alternative to polymorphic associations and would provide a nice baseline.

I personally am still inclined to use a join table rather than polymorphic associations. It’s very rare that I have something that needs to be “promiscuous” enough that I won’t be able to know up-front what needs to be joined to what. I tend to prefer it because I can add constraints to the join table to ensure one side is unique, for example. It also leaves room open in case I need to add other information to the relationship (as I often do) such as the time the relationship was created/updated, etc.

]]> By: Nick Gauthier http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-65 Nick Gauthier Sat, 14 Jun 2008 14:21:22 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-65 Hey Eric, I was thinking about that too. When the current benchmark finishes I'll add in two more tables with full indexing (unless you want to do it :-D). -Nick Hey Eric,

I was thinking about that too. When the current benchmark finishes I’ll add in two more tables with full indexing (unless you want to do it :-D).

-Nick

]]> By: Eric Allam http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-64 Eric Allam Sat, 14 Jun 2008 13:16:00 +0000 http://blog.smartlogicsolutions.com/2008/06/13/ruby-on-rails-polymorphic-association-benchmarks/#comment-64 Usually you'd want to create an index that indexes on both the type and the id columns. Usually you’d want to create an index that indexes on both the type and the id columns.

]]>