More over here.

There are really 2 ways of connecting to a database for an app: either directly or through a “layer” (some would call it a database abstraction layer, others an API, others a webservice, others something else).

If you’re using an abstraction layer of some kind, this point is moot because you can recode that to do this.

But, many of today’s web apps aren’t using anything like this.

What they do is create a connection “template”. Then whenever they need to talk to the database, they pull those details down, or create that object and they talk to it.

There’s nothing wrong with this, in principle. The problem is that not all connections to databases are created equal. On a blog, for example, there might be tens of thousands of “read” requests (ie: someone wanting to see the page), but very few “write” requests (someone making a comment or the author creating a new post).

As a result, one of the ways of creating higher performance, higher availability applications is to make only one database server handle the “writes”. Then you have lots of tinier database servers that handle the “reads”.

If your entire application is built in such a way that changing this would be a major issue, you’re in deep trouble if it ever makes sense to go to the above kind of architecture.

Hope that paints a mildly clearer view of things… There are a lot of ways to do this type of thing, though. Taking care of the simple things up front can help dramatically down the road.