Ruby on Rails

On 3 April 2012 22:30, Fearless Fool <lists@ruby-forum.com> wrote:
> Let me redact that previous post...my only excuse is that I hadn't had
> my coffee yet!
>
> If the time to make a DB query (let's call it 1 Unit of time) swamps out
> any amount of processing in Ruby, then:
>
> Approach A (do a SELECT to check for existence of the record before
> attempting an insert) will take 1 Unit if the record exists and 2 Units
> if the record does not exist.
>
> Approach B (always attempt the insert, let the DB signal an error,
> recover by doing a SELECT) will take 2 Units if the record exists and 1
> Unit if the record does not exist.
>
> So I'd conclude that:
>
> If the chance of a duplicate insert is less than 50%, you're better off
> with Approach B, otherwise you should choose Approach A.

I don't know for certain but I imagine a db write takes much longer
than a db read, maybe 10 units for the write and one for the read. If
so then that changes the calculation somewhat. However there is also
the question of whether db access time is significant in the app
anyway. Bottlenecks in apps are usually not where you expect them to
be. I would do it the way that seems cleanest to you and only worry
about optimisation if throughput becomes an issue, in which case you
will have to do some profiling to find where the bottlenecks are.

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.