Comments on: Scaling Rails the eBay way http://blog.amber.org/2006/12/07/scaling-rails-the-ebay-way/ Thoughts of a minor lunatic Wed, 21 Oct 2009 01:55:36 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: links for 2006-12-08 at tecosystems http://blog.amber.org/2006/12/07/scaling-rails-the-ebay-way/comment-page-1/#comment-46278 links for 2006-12-08 at tecosystems Fri, 08 Dec 2006 05:35:10 +0000 http://blog.amber.org/2006/12/07/scaling-rails-the-ebay-way/#comment-46278 [...] Scaling Rails the eBay way : Pensieri di un lunatico minore “One, it emphasis horizontal scaling over everything. Second, and more interesting in a Rails-context, is that they have pulled nearly all business logic out of the database (Oracle).” - interesting thoughts on eBay from Chris (tags: Petrilli Rails eBay horizontal scaling database logic joins) [...] [...] Scaling Rails the eBay way : Pensieri di un lunatico minore “One, it emphasis horizontal scaling over everything. Second, and more interesting in a Rails-context, is that they have pulled nearly all business logic out of the database (Oracle).” – interesting thoughts on eBay from Chris (tags: Petrilli Rails eBay horizontal scaling database logic joins) [...]

]]> By: Reinout Heeck http://blog.amber.org/2006/12/07/scaling-rails-the-ebay-way/comment-page-1/#comment-46262 Reinout Heeck Thu, 07 Dec 2006 22:10:58 +0000 http://blog.amber.org/2006/12/07/scaling-rails-the-ebay-way/#comment-46262 I ran into this surprise a couple of times. I program with several others and not all of us are database savvy (I'm one of those...) so we tend to do more in Smalltalk than in the DB. When our (my) code gets reviewed people suggest that such functionality should be delegated to the DB, so people alter my code to 'make it so', the end result has been several times a deterioration of performance. On several small tables we even found that it is cheaper to even do selects in Smalltalk as opposed to having the DB do it, just download the entire table into St and code 'normal' Smalltalk rather than SQL since this is faster :-) I ran into this surprise a couple of times.

I program with several others and not all of us are database savvy (I’m one of those…) so we tend to do more in Smalltalk than in the DB. When our (my) code gets reviewed people suggest that such functionality should be delegated to the DB, so people alter my code to ‘make it so’, the end result has been several times a deterioration of performance.

On several small tables we even found that it is cheaper to even do selects in Smalltalk as opposed to having the DB do it, just download the entire table into St and code ‘normal’ Smalltalk rather than SQL since this is faster :-)

]]>