Qlik Community

Qlik Sense App Development

Discussion board where members can learn more about Qlik Sense App Development and Usage.

New Contributor III

Best Practice for Creating QVDs

I'm curious what process other companies/teams follow for creating QVDs.  We're fairly new to Qlik Sense (initial implementation was less than a year ago).  The way we've set things up initially, only our Root Admin can create data connections, and create and/or manually refresh QVDs - in Dev, QA, and/or Prod.  This has helped us to ensure standard naming conventions and processes across all QVDs and teams, and our Root Admin has been very responsive and has so far been able to keep up with the QVD and data connection requests.

However, as we ramp up and roll out Qlik to more teams and developers and create more apps and QVDs, we are considering whether we should also allow Developers and/or Team Admins to create and manually refresh QVDs - at least in Dev. 

I'd love to hear how other companies handle this, though.


Tags (1)
3 Replies
Contributor III

Re: Best Practice for Creating QVDs

Hi Steve,

I am not entirely sure I fully understand what you are after, but I think you want to know how to let more and more people use the QVD files created from your data sources as the interest in Qlikview grows in the organization.

I would recommend using a strict ETL (Extract-Transform-Load) for your environment, which in short works as follows:

- Extract; Data is extracted as is from the data source (basically LOAD * from DataSource) and then saved as QVD's without any formatting. File names would be the same as the name of the data source location to show where the data is coming from. No calculations or modification to any data is made at this point. It's simply a snapshot of the data base as it was.

- Transform; Takes the needed extract QVD's and makes sure to trim unneeded columns, set date format, divide into multiple smaller tables etc. Basically creates the QVD's that are suitable for the applications. These newly created tables will then be stored as QVD's by themselves in a 'Transform' folder naming them for what they are (eg 'Calendar', 'TransactionRows' etc). These QVD's can both be shared over different applications, or be very specific for the need of a certain application. The point is to make all aggregations and pre-calculations in this step so that they can easily be maintained if many users are referring to them in different front end applications.

- Load; This is the end user applications, and the calculations done here should be a minimum (as it was prepared in the Transform step already. Basically LOAD * from Calendar.qvd (qvd);. Loading QVD's like this goes extremely fast and resource efficient.

The reason why we use the above are many, but a few highlights include;

- Raw data is easily accessible for anyone who needs it

- Front end applications will always be up and running (if the extract or transform stages fail, the load will still use the older QVD's from the previous run).

- It allows for many users to reuse the same extract qvd's.

- Recurring and common calculations can easily be modified in the Transform step and benefit all users that will load that specific qvd in the load step.

Hope the above was at least slightly helpful Let me know if anything is unclear.

Valued Contributor

Re: Best Practice for Creating QVDs

New Contributor III

Re: Best Practice for Creating QVDs

Thanks Niclas.  This was definitely interesting and helpful information.  However, I'm not so much looking for guidance on HOW to create QVDs - what I'm actually looking for is WHO should be responsible for creating QVDs.

For us, our two root admins are the only ones able/responsible for creating QVDs.  When a developer needs a new QVD created, or an existing QVD manually refreshed, we have to send a request to the root admins to do that for us - developers cannot do this themselves.

I'm just trying to see how other organizations handle this process - i.e. what role handles the responsibility for creating QVDs.


Community Browser