It probably is, but why were you putting the data into a database? If there's a valid reason to do that, do it and then fix db performance with caching if it becomes a limiting factor.
If there's not a valid reason to put the data into a database, why would you do so? Start with the simplest thing that would possibly work to get your tests passing and go from there. There was some discourse on one of the agile-like lists (maybe the XP list) recently with some people suggesting you shouldn't actually add support for a db to an app until you have the first test that won't pass simply by using in memory representations. That's a little extreme for me, but certainly I wouldn't put stuff into a db unless there was a good reason. And if there is a good reason for it being there, I wouldn't remove it for performance reasons until I had failing performance tests and profiling that pointed to that query as being part of my problem. Google "premature optimization" Best Wishes, Peter On Jan 12, 2011, at 4:45 PM, Me wrote: > I would think that a select box populated by an array or hash is MUCH faster > and less system intensive than doing any db lookup. > > -- > 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. -- 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.
