The solution you describe is also known as a multi-tenant, where multiple customers data is stored in one DB. There are a lot of benefits of this approach (one backup, less DB management, etc)
The big problem I have seen with this in the field is that if you have bugs in your SQL, it is quite easy for a SQL SELECT statement to pull multiple companies' data if you forget (or make a mistake) with the WHERE COMPANYID='xxx'. If you botch this, suddenly your customer may see ANOTHER customer's data on their screens. When this happens, customers freak out!
Similarly, if a hacker manages to perform a SQL injection attack, they may be able to see data for all customers, just by getting into your one database.
So, the alternative is to give each customer their own database. And connect to a different database depending on the company/customer that logs in. Then it is not possible to get data from ANOTHER company by accident. But it can be harder to manage. For example, there are often limits on the number of databases a single database server can handle.
So what to do? Most customers are not going to care that much, and if you do a great job, you'll never see a problem. If you are careful, a multi-tenant solution is easier to maintain and may be easier to develop.
I have also worked at companies where ONE customer was so picky that they required their own database -- even though the solution was multi-tenanted. And we did it for them to get the deal.
There are a lot of resources on this issue on the internet:
- Stack Overflow discussion
- Joel Spolsky talked about it on his podcast here