Basic QVD Questions

[DMG]

Hi i've read the documentation for QVD files but have some questions i hope someone can help me with.

1. I understand that a QVD file is a way to store loaded data in an efficient format, does this actually improve the performance of an app or does it only improve the performance of an app when it loads. 

For example, if i have a table running slow because it contains 200k rows of data, if i convert to using qvd's rather than an excel data load, will that actually improve the performance of the app when a user is using it, or does it only improve the app load time for that user, or even just the dataload load time when an app is refreshed ?

2. Can someone provide some examples of how to put data that would normally go in via an attached file load, into a qvd instead, and then how to load that data from the qvd rather than the attached file.

3. Do you need to put you qvd creation code in a separate app rather than the same app using the data, if not, does the system realise that the data loaded via the attached file is ignored and instead the data is used from the qvd load that appears later in the data load code, even if the field names exist in both.

Sorry if i've not grasped qvd's properly  but trying to understand them better.

Would also be interested in any tips on improving performance of a loaded app at the end user experience.

[Or · Accepted solution]

1. QVDs have no impact on the performance of apps because they aren't actually a part of the app. They're merely a way of storing (and reading) data to/from apps. Any impact in this regard will be in the script's load time, not in the performance of the app when facing the user.

2. You simply store the data to a QVD using STORE, after reading it from the original data source.

3. You do not need to put your QVD creation code in a separate app. However, this is often the recommended approach with Qlik's two-tier or three-tier apps:

First app - loads the data from the underlying sources (DB, files, etc) and stores it to QVDs

Second app - Loads the data from the QVDs and manipulates it as required. This app may also contain the user-facing content if no third app is used.

Third app (Optional) - reads the result of the second app, often using binary load, and contains the actual user-facing content.

Using this approach lets you modify your app without having to reload information from the underlying sources each time - the information is saved in QVDs and can be reloaded quickly. You still need to reload from the underlying source if you're changing the source data, of course, e.g. adding a table from your DB, changing an underlying query, etc.

None of this is related to how quickly the user-facing app will perform, though. If performance is slow, the issue might be with the data schema, with inefficient formulas, with tables that return too many rows (typically, a user-facing table shouldn't return 200,000 rows, your user isn't going to read 200,000 rows), but there can be any number of other factors and you'd have to dig into the specific issues with your app(s).