You "can't" store two tables into one QVD, so you would store each table as its own QVD.
I guess I could stop there, but in case you don't know, or for others who stumble across this later that might not know, you actually have some options here, and what's best is somewhat a matter of QlikView data management philosophy, and what your company has settled upon as a standard for your data architecture, if any.
Storing each table as its own QVD is in line with a three-tier QVD architecture. This is a common and I think very good architecture where you have two layers of QVDs - the base extract QVDs, and the transformed QVDs. The extract QVDs are just simple loads from your real company data with minimal manipulation. I'm guessing your InvoiceDB.qvd and ClientDB.qvd are extract QVDs. Then from that you can build transformed QVDs which have been massaged into QlikView-friendly tables, data structures that might barely resemble the source databases. So storing your new tables as QVDs would be creating this transformed QVD layer. You might call them Invoice.qvd and InvoiceDateKeys.qvd, using "DB" to indicate that a QVD is a direct extract, and the absence of it to indicate a transformed QVD ready for load into user applications. Probably a different directory too. And this could be made a company standard, that you always have extract QVDs and transformed QVDs, and you only load real company data into extract QVDs, only read extract QVDs to build transformed QVDs, and only read transformed QVDs in the user applications. You might be creating a lot more for one application than you initially require, but you're set up in an organized way that supports expansion.
Another approach would be for the transformed layer to be QVWs instead of QVDs, called a three-tier mixed QVW architecture. So in your case you'd store this whole script as a ClientSales.qvw, but that wouldn't be your user application. Instead, you'd do a binary load of ClientSales.qvw to pull in the entire data model all at once. You're storing a QVW instead of two QVDs, and doing a binary load of the QVW instead of a load of each QVD.
There are other approaches, like single-tier (raw data -> user app), two-tier QVD (raw data -> QVD -> user app), and two-tier QVW (raw data -> QVW -> user app).
In practice, my company's architecture most closely resembles a two-tier QVD architecture, but that's not the rule we're following. We're following what we call "the rule of one". If data is only used in one user application, we'll typically load it directly from the data source into that user application (single-tier). But once we need it in another user application, we go back and build a QVD for it at that time, and modify the original application to load the QVD (two-tier QVD). Same with transforming data. If we only need the data transformed in one user application, we'll do the transformation in the user application (two-tier QVD). If in more than one, we'll build a transformed QVD (three-tier QVD). If all user applications need the same transformed QVD, and none need the extract QVD, we won't create an extract QVD (two-tier QVD). Maybe you could think of it as creating the minimum number of QVD tiers necessary to avoid duplicating the same script in more than one QVW. This rule is only loosely followed. For instance, if I expect some data will eventually be used in more than one place, I might go ahead and build a QVD for it, even if I only need it in one application right now. Anyway, I'm guessing that in our shop, the tables we just built would only be used in one place, and so I'd just put all this script in a user application and not store the transformed tables as QVDs.
