Dan Ahern: AFAIK, the named finders are *not* a performance problem. I haven’t verified this in the ActiveRecord source code, but I remember reading (on the Rails list?) that AR is rather clever in this regard.

Basically, IIRC, method_missing is invoked *only the first time* that a named finder is encountered, then it caches the method for future calls. I guess it would be something like this (in concept, not necessarily implementation):

class Person < ActiveRecord::Base
  def method_missing(name, *args, &block)
    if name.to_s =~ /^find_by_/
      method = Proc.new { #some dynamic finder code }
      class << self.class
        self.define_method(name, method)
      end
      self.send(name, *args, block)
    end
  end
end

…so that the first time Person.find_by_name is called, you do incur the method_missing overhead — but the second time Person.find_by_name is called, it exists as a real method, so method_missing doesn’t come into play.

So don’t worry about dynamic finders for performance, so long as you’re not using too many different ones.

One thing while I was digging around in to the BDD world that I found today was Squirrel by ThoughtBot.

http://www.thoughtbot.com/projects/squirrel/

This allows for Ruby blocks into the find method. I haven’t had a chance to use this yet but I think it would help to move completely out of the ActiveRecord Array conditions syntax.

Second, what I would recommend rather than using the array conditions method is to instead switch over to using a hash, much of the issue would be easily solved by using the hash. For example
Client.find(:all, :conditions => {:notify_by => %w(email txt both)}) will generate an sql query SELECT * FROM clients WHERE notify_by in (’email’,'txt’,'both’);

With the new Rails 2.2+ you can do neat things with the conditions hash as well like putting a condition for another table.
Client.find(:all, :conditions => {’projects.payment_type’ => %w(paying nonpaying both)}, :join => :project)
will generate
SELECT * FROM clients LEFT JOIN projects on clients.id = projects.client_id WHERE projects.payment_type in (’paying’,'nonpaying’,'both’);

You also aren’t just limited to arrays.
Client.find(:all, :conditions => {:activated => true})
Will generate the expected where activated = 1
Client.find(:all, :conditions => {:created_at => (Time.now-30.days)..Time.now})
Will generate created_at BETWEEN (’2009-04-1′, ‘2009-04-30′)
Client.find(:all, :conditions => {:agent => nil})
Will generate agent IS NULL

The only time you should need to slip back to your array conditions is when you have to do less than () or when dealing with much more complex conditions statements.