Re: [Rails] Re: Re: Best way to handle multiple tables to replace one bi

On 26 April 2010 02:08, Mike P. <lists@ruby-forum.com> wrote:
> Thank you Colin and Marnen for your repsonses.
>
> Marnen Laibow-Koser wrote:
>> Colin Law wrote:
>>> On 25 April 2010 00:45, Mike P. <lists@ruby-forum.com> wrote:
>>>>...
>>>> I think if people could just get over the "don't optimize too early"
>>>> mantra, and realize that this can't possibly be best move for everyone,
>>>> a lot of future stress could be avoided, for both the business owner and
>>>> the customer.
>>>
>>> Optimising "too early" is a bad thing by definition.  If it was a good
>>> thing then it would not be "too early".
>>
>...
>
> And what about the cases when your research shows that based on the
> expectations for the table (lots of insertions and deletions, table gets
> increasingly large as new users come in, etc.), that the evidence
> suggests that this particular table will have the same issues as the
> tables mentioned in the other posts?

If you absolutely _know_ that there is going to be an issue with the
performance then it is not premature optimisation, it is part of the
specification of the app. If however, as you say, "the evidence
suggests that this particular table will have the same issues ..."
then it is only a suggestion and not a certainty, so what is the point
of doing up-front work delaying initial deployment? Particularly when
the suggested optimisation may not be the best way of solving the
problem (which may never occur).

A long career in s/w development has shown me that the key performance
issues in an app are very rarely in the areas that one expected at the
start.

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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.