Don't forget, you can also add a database index to a field that is going to be searched often, that will improve search performance.
In your model's migration: add_index(table_name, column_names, options) from: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html <http://api.rubyonrails.org/classes/ActiveRecord/Migration.html> On Tue, May 17, 2011 at 08:01, Colin Law <clan...@googlemail.com> wrote: > On 17 May 2011 11:06, comopasta Gr <li...@ruby-forum.com> wrote: > > Colin Law wrote in post #999008: > >> .. > >> Why store the tag identifier in the statistic? > > > Externally the tag is known by its identifier. They are tags that are > > read with the mobile and when they come to the server they are found by > > this identifier. When a stat is created the tag where it belongs is also > > found by the identifier (creation of a stat is not triggered by a tag > > being read). > > > > Yes, when the stat is created I could first use the tag identifier I > > get, find the internal tag ID and actually store that internal ID with > > the stats instead of the identifier. Then the relationship would be > > complete. But I guess I was trying to save that db call since if I would > > use the identifier for both that call wouldn't be needed. > > It is almost always a bad idea to store the same data twice in the > database (or in this case many times, in the tag and in each > statistic). One issue is that it becomes very difficult to edit the > tag as you have to change it in all the statistics, and the updates > have to be protected by transactions in case a problem arises half way > through. My advise is always to do it the simplest way initially and > only worry about efficiency if such a problem arises. The bottlenecks > in an app almost always turn out to be not where they are initially > expected and time spent optimising the app before problems arise is > time wasted. Also by ending up with more complex code then bugs are > more likely and can be more difficult to fix. > > Also in Rails it is almost always best to stick to the conventions > (using id as the primary key in this case), the conventions can be > overridden but usually this just adds complexity and makes life more > difficult. > > Colin > > 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 rubyonrails-talk@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com. > 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 rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
