Hacker News Reader

Comment by niels | Hacker News Reader

I'm confused... why would they ever come up with a solution like this?

I assume by "like this" you mean a separate db for each customer.

The reason is probably a perceived improvement in security. I've worked in systems where they've done this for security reasons. I believe Joel Spolsky did it for this reason when he was betaing a release of product (FogBugz?).

It certainly does jack up the maintenance overhead. I wouldn't design a system this way myself.

I'm really curious if this is in fact a common practice out there in the wide world.

"It certainly does jack up the maintenance overhead."

A bit of automation would solve this problem,as far as I can see it.

"I'm really curious if this is in fact a common practice out there in the wide world."

It is. I've worked for companies which do this, and have scaled with Oracle for several tens of thousands of customers (=databases).

Also, complex reports that require hand-coded SQL becomes that much simpler. (Compared to having all customers' data in a single database)

It makes it dead simple, among other things, to export the companies data should the company wish that.

I mean, any other export would just be the result of some query. And it doesn't have to be a complicated query, either. Just "WHERE customer_id=5" or whatever.

Or am I missing something?

There are lot of cases where the query will indeed be complicated. Reports, for example. I have seen SQL queries reports which are quite complex, making sure that such SQL is always qualified with WHERE customer_id=5 is a maintenance nightmare.

There is also the customer perception thing, as petethomas said in this thread.

Scaling, it provides cheap, quick sharding from Day 1. If your db is overloaded, just move some to a second machine. FB used a similar approach with mysql and isolated university databases in the early days, I believe.

Reply on news.ycombinator.com