On 20 October 2011 15:53, Peter Hicks <[email protected]> wrote: > On Thu, Oct 20, 2011 at 01:24:24PM +0100, Colin Law wrote: > >> In any case you should not worry about efficiency at this stage. >> Start with the most straight forward design and *if* performance >> becomes an issue then optimise it later. I can virtually guarantee >> that the bottleneck in a app will not be where you expect to be at the >> outset, so starting with a more complex (and potentially buggy) >> solution in order to work around perceived bottlenecks is rarely a >> good idea. > > Very wise words which only make sense when somebody else utters them. > > Thanks, Colin - I'll give this a go!
Another solution might be to have a table of options (or whatever word is appropriate), where option.name is 'TB', 'TF' and so on. Then you can have a HABTM relationship between the tables and you could get all the options for your main object using @my_object.options which would give you (effectively) an array of the options. This would have the advantage of flexibility in that you can add further options if you need to. Also it gives you somewhere to store further information about the option. It all depends on the details of the problem you are trying to solve. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
