.Net'ers

As someone whose background has been in development of business applications (specifically around Microsoft technology), when I started working with QlikView a ways back, it was a transition. Sure, you’re still building something using technology for end users, but it requires a different way of thinking. Here are some tips to keep in mind when starting with QlikView if you come from a traditional software development background.

1. Learn that denormalizing your data isn’t a bad thing. As someone who has worked a lot with relational databases I always want to split things out into separate tables. With QlikView, because of the way data is stored and the internal compression routines, denormalizing data into fewer tables is often times a better idea. This is not true in every situation, but don’t be afraid to denormalize your data.
2. Put as much as you can in your load script and not in formulas on objects. The load script runs when the data is loaded the first time whereas the formulas in objects are run every time a user makes a change to their selections or changes screens, which can slow things down.
3. Use variables to represent the path to your QVD files. Surprisingly, I’ve seen a number of instances where when loading from multiple QVD files, the same path is included in each load statement. This becomes troublesome if you want to change the location of your QVD files because you’ll have to change it in multiple places. If you use a variable, you only have to change it once.
4. You have to think about what you want to report on and keep in mind sometimes you need to report on what is NOT there. For example, let’s say you have a visualization where you report on the total items sold every Monday. For a few Mondays, though, there is no data in your source because that Monday was a holiday and the source doesn’t include zero values. You now have a gap in your data. Here is a good place to do something in your load script to include those zero values. Maybe you could create a master calendar (in the form of a table) of all Mondays and add it to your table, so every Monday has a value.
5. If you control the source data, learn to think about the lowest level of data that you’ll need. Let’s say that you have a set of dashboards/visualizations with football statistics. What level do you need statistics for? Is it the totals by player for a game or do you need to get down to the play level? The difference here would be that if you only have totals for a game, you couldn’t look at a given players rushing yards in the 1st quarter vs. the 4th quarter across the season. If you have the play-by-play data, then you could track that information. Keeping this in mind can also be helpful to determine the best way to group data if using a group by statement.
6. Comment your code. If you have any development experience, this should be nothing new. And don’t use comments like “Load the customer data.” That should be pretty obvious from the Load statement itself. Explain things that are unusual, tricky, or difficult. Explain why you’re doing something, not what you’re doing.
7. Don’t try to do tricky things in formulas where you’re overriding the user’s selections or doing things that change what the user sees without them knowing that you’re doing something behind the scenes. It will confuse them.
8. Clean up items in your load script. If you use a temp table, drop it as soon as you don’t need it anymore.
9. Use friendly names for your fields. “Rate Effective Date” is much easier to read for a user than CUSTOMER.RATE_EFF_DATE. This will take you a bit more work, but you’re doing this for the users, not yourself.
10. Don’t be too concerned if your load script takes a while to run (unless the time exceeds your reload schedule) because it only happens when you’re loading the data and your users won’t even see the load. Worry about performance if things take a long time when a user makes a selection.

Hopefully these will help someone as they get started with QlikView. Just like any other software, learning QlikView takes time. It can be especially daunting if you’re not used to working with BI tools but are used to software development.