Best practice in this situation?

[Tenn Seven]

I am setting up a database for an application and some of the entities look like this:

Client --> Communications --> Images

A client would be a client entity, a communication would be a specific communication having to do with a specific client, and an image would be a single page from a single communication.

Seems simple enough, but what gives me pause is that there could be 1 to say 100 clients on the high end, and there could be hundreds of thousands of communications per client (let's say 500k-600k on the high end, and 40k on the low end), and each of those communications could have any number of pages, (normally 2-3, but hundreds in rare occasions and the very rare communication might have toward a thousand pages). Needless to say, these numbers that the Communications and Images tables could contain massive numbers of rows.

So, where normally I would store all of the communications in the Communications table with a foreign key reference back to the Client table, and all of the pages in the Images table with a foreign key reference back to the Communications table, it seems like the numbers here will just be too big. Do I separate the tables, like Communications_Customer1, Images_Customer1; Communications_Customer2, Images_Customer2, so on and so forth? Should the customers themselves each be a separate database on the server? Or am I worrying about nothing?

Any advice or link to advice on best design practices when dealing with information on this scale would be greatly appreciated.

Thanks!

-TennSeven