I'm not aware of a resource for making these types of decisions except for common sense and experience. You could go to a consulting firm or bounce the ideas off of a research firm like Gardner.

You have to weigh costs, benefits and risks. For example, splitting up each client into a seperate database means added maintenance because you have to backup more databases, run consistency checks on more databases, update statistics, defrag indexes... you get the picture. Plus, you have to create mechanisms for maintaining common data available across each database and mechanisms for gathering information that you want from these databases. That is set against the ability you'll gain to isolate each client from the others, easily, for security. Also you'll be able to scale each client independently, even seperating them to other servers as needed. You can also provide database tuning individually for clients that use some part of the app more than others. Also, by splitting up the client databases, you reduce the risk to all clients if one database gets corrupted.

See, you can go around and around with it. You just have to make the decisions within your own environment. Largely, I'd say, it really depends on size. If each of the database is 5gb, it's probably not worth all the labor to split them apart.