Brown trousers time :~

[Paul Orrock]

Jonathan Stowe wrote:
> 
> It won't make any difference whatsoever - the same engine has to deal
> with the requests anyway. Separate databases just makes your design less
> rational and will add overhead at the language layer.

Agreed. What you may want to consider though is having two types of 
database handles within your application. One with only select priv's 
and one which has select and everything else you need.

With most web apps a lot of the front end rendering only requires select 
priv's, for example showing products in a category ordered by price.

This means that one easy way of getting better performance is that you 
set up a slave MySQL server listening to your master and farm the 
selects off to the slave leaving the master to do updates, inserts and 
instant update dependent selects (e.g. items in a basket) as opposed to 
products in a category.

Personally I reckon that if you've got rid of all the major code 
bottlenecks and are spending ages trying to shave another second or two 
off processing something then it's a better option to throw more 
hardware at it.

For spending 500 quid you'll save yourself time, add resilience, and get 
a much better client throughput than that saving that second will give you.

regards,

Paul