Comments for Quick - Qlear - Qool http://www.quickqlearqool.nl it's all about QlikView Fri, 03 Sep 2010 05:31:37 +0200 hourly 1 http://wordpress.org/?v=3.0.1 Comment on I forget: what’s in memory? by Juan http://www.quickqlearqool.nl/?p=1205&cpage=1#comment-3996 Juan Fri, 03 Sep 2010 05:31:37 +0000 http://www.quickqlearqool.nl/?p=1205#comment-3996 Hi Gilles, this is a great post that helps clarify the confusion around all the different "in-memory" approaches. It would be good to have a clear ranking of these solutions in areas such as: ease of development, ease of use, performance/scalability and cost. Juan. Hi Gilles,
this is a great post that helps clarify the confusion around all the different “in-memory” approaches. It would be good to have a clear ranking of these solutions in areas such as: ease of development, ease of use, performance/scalability and cost.
Juan.

]]> Comment on Enterprise BI vs Departmental BI? by Juan http://www.quickqlearqool.nl/?p=1064&cpage=1#comment-3925 Juan Thu, 29 Jul 2010 01:14:02 +0000 http://www.quickqlearqool.nl/?p=1064#comment-3925 Hi Kribo, for each table->QVD load, you will decide whether it is appropriate to run a full load or an incremental load appending to an already existing qvd file containing historical data. The main reason to implement incremental loads is to reduce the time it takes to run a reload process. In some environments a 2 hour reload is not a big deal, but in others it is unacceptable. This may be due to tight batch windows, process dependencies and/or a requirement specifying early availability of a QlikView document. The typical candidates for incremental loads are big tables (i.e. several million records), particularly when SQL query performance is slow due to network or source DB issues. There is an introduction on how to implement incremental loads in the QlikView Reference Manual, but it would be an interesting topic for a new post. Hi Kribo, for each table->QVD load, you will decide whether it is appropriate to run a full load or an incremental load appending to an already existing qvd file containing historical data.
The main reason to implement incremental loads is to reduce the time it takes to run a reload process. In some environments a 2 hour reload is not a big deal, but in others it is unacceptable. This may be due to tight batch windows, process dependencies and/or a requirement specifying early availability of a QlikView document.
The typical candidates for incremental loads are big tables (i.e. several million records), particularly when SQL query performance is slow due to network or source DB issues.
There is an introduction on how to implement incremental loads in the QlikView Reference Manual, but it would be an interesting topic for a new post.

]]> Comment on Enterprise BI vs Departmental BI? by kribo.alim http://www.quickqlearqool.nl/?p=1064&cpage=1#comment-3922 kribo.alim Thu, 22 Jul 2010 04:03:25 +0000 http://www.quickqlearqool.nl/?p=1064#comment-3922 hi.. how to update the QVD? is it going to add or reload it from the beginning? hi..

how to update the QVD?
is it going to add or reload it from the beginning?

]]> Comment on QlikView from a MicroStrategy Consultant’s Perspective by Jane http://www.quickqlearqool.nl/?p=357&cpage=1#comment-3912 Jane Thu, 15 Jul 2010 20:40:20 +0000 http://www.quickqlearqool.nl/?p=357#comment-3912 The beauty and efficiency of the centralized metadata with MicroStrategy is that it's built once (quickly) and available across all applications (immediately), whether Mobile, Web-based, or Desktop. This kind of "Build Once, Deploy Anywhere" is one of the many things that companies love about MicroStrategy software. The beauty and efficiency of the centralized metadata with MicroStrategy is that it’s built once (quickly) and available across all applications (immediately), whether Mobile, Web-based, or Desktop. This kind of “Build Once, Deploy Anywhere” is one of the many things that companies love about MicroStrategy software.

]]> Comment on New Qlikview video, about the in-memory advantage by Gilles http://www.quickqlearqool.nl/?p=1197&cpage=1#comment-3908 Gilles Wed, 14 Jul 2010 08:01:39 +0000 http://www.quickqlearqool.nl/?p=1197#comment-3908 OK, to conclude this conversation, and correct me if I'm wrong, we all think qlikview is a great product! Looking back at my post, where I claimed you DO NEED a datawarehouse, that might be a little bit exaggerated. It is not a "DO NEED" in all cases We all think that Qlikview in some cases can be sufficient to provide the required solution. This can be to provide the "last mile" as Scott states in an environment with an existing DWH, or with relatively small or departmental deployments, or with relatively simple and stable data structures. We also agree that there are solid reasons to not have qlikview as your DWH/ETL replacement, vizubi and Gilles state that storing data exclusively in qlikview represents a big risk. Also maintenance costs will rise with complexity of your data structures! Thanks, Gilles OK, to conclude this conversation, and correct me if I’m wrong, we all think qlikview is a great product!

Looking back at my post, where I claimed you DO NEED a datawarehouse, that might be a little bit exaggerated. It is not a “DO NEED” in all cases

We all think that Qlikview in some cases can be sufficient to provide the required solution. This can be to provide the “last mile” as Scott states in an environment with an existing DWH, or with relatively small or departmental deployments, or with relatively simple and stable data structures.

We also agree that there are solid reasons to not have qlikview as your DWH/ETL replacement, vizubi and Gilles state that storing data exclusively in qlikview represents a big risk. Also maintenance costs will rise with complexity of your data structures!

Thanks,
Gilles

]]> Comment on Nice Read: Save the Pies for Dessert by william http://www.quickqlearqool.nl/?p=669&cpage=1#comment-3905 william Tue, 13 Jul 2010 11:00:55 +0000 http://www.quickqlearqool.nl/?p=669#comment-3905 Hi Diederik, That's definetly true which is also stated in the last alinea of the article: The fact remains that a comparison of two sets of summed parts is rare in the real world. But, by all means, should you ever need to display data for this purpose, a pie chart would serve you well. Otherwise, save the pies for dessert. Hi Diederik,

That’s definetly true which is also stated in the last alinea of the article:

The fact remains that a comparison of two sets of summed parts is rare in the real world. But, by all means, should you ever need to display data for this purpose, a pie chart would serve you well. Otherwise, save the pies for dessert.

]]> Comment on Nice Read: Save the Pies for Dessert by Diederik http://www.quickqlearqool.nl/?p=669&cpage=1#comment-3900 Diederik Sat, 10 Jul 2010 19:12:58 +0000 http://www.quickqlearqool.nl/?p=669#comment-3900 OK, but what about showing 2 values? It's a great way of showing the relationship between good/bad in a dashboard... OK, but what about showing 2 values? It’s a great way of showing the relationship between good/bad in a dashboard…

]]> Comment on New Qlikview video, about the in-memory advantage by Vizubi http://www.quickqlearqool.nl/?p=1197&cpage=1#comment-3887 Vizubi Wed, 07 Jul 2010 15:34:45 +0000 http://www.quickqlearqool.nl/?p=1197#comment-3887 I think that there are two main issues here. The first is the issue of using QlikView to do ETL directly from transactional systems. The second is the issue of using QlikView as the only repository of that data. Regarding the use of QlikView for ETL, I have the following thoughts: - QlikView scripting language allows you to do this in a feature rich way. - The language is quite complex - For highly heterogenous data coming from multiple systems or if the data structure of the source data is complex, creating a functional ETL process in QlikView is expensive in terms of resources and maintaining such a structure in my opinion would be very costly. Conclusion: QlikView for ETL could be an appropriate solution for organizations with relatively simple and relatively stable data structures, but the cost rises rapidly with the complexity of the source data. Regarding the use of QlikView for data storage I have the following thoughts: - Data stored in various QlikView formats (qvd, qvw) is not accessible using other tools - Exporting data from QlikView format is not a particularly functional option; possible but not particularly efficient (in the time = $ sense) - I fully agree that you'll never know what you might want to do with your data and having to re-create the whole ETL process because your data is not readily accessible is clearly a big risk. Conclusion: Storing data exclusively in QlikView represents a big risk, but QlikView is more then a frontend for a traditional DWH. I think that there are two main issues here. The first is the issue of using QlikView to do ETL directly from transactional systems. The second is the issue of using QlikView as the only repository of that data.

Regarding the use of QlikView for ETL, I have the following thoughts:

- QlikView scripting language allows you to do this in a feature rich way.
- The language is quite complex
- For highly heterogenous data coming from multiple systems or if the data structure of the source data is complex, creating a functional ETL process in QlikView is expensive in terms of resources and maintaining such a structure in my opinion would be very costly.

Conclusion: QlikView for ETL could be an appropriate solution for organizations with relatively simple and relatively stable data structures, but the cost rises rapidly with the complexity of the source data.

Regarding the use of QlikView for data storage I have the following thoughts:

- Data stored in various QlikView formats (qvd, qvw) is not accessible using other tools
- Exporting data from QlikView format is not a particularly functional option; possible but not particularly efficient (in the time = $ sense)

- I fully agree that you’ll never know what you might want to do with your data and having to re-create the whole ETL process because your data is not readily accessible is clearly a big risk.

Conclusion: Storing data exclusively in QlikView represents a big risk, but QlikView is more then a frontend for a traditional DWH.

]]> Comment on New Qlikview video, about the in-memory advantage by Scott http://www.quickqlearqool.nl/?p=1197&cpage=1#comment-3886 Scott Tue, 06 Jul 2010 21:27:17 +0000 http://www.quickqlearqool.nl/?p=1197#comment-3886 Interesting conversation and this is the subject of an upcoming blog I've written for our website. The data world is not a tidy place, and there's no tidy answer to this. For everyone who asserts you always need a data warehouse, I can (and have) found IT folks who will concede that the majority of data warehouse implementations fail to deliver the business value anticipated or expected when they were started. But I would never use that fact to assert one shouldn't bother with a warehouse. I CAN point to folks replacing their data warehouse with QlikView (I did at Pergo) or this gentleman: http://histalk2.com/2010/05/03/readers-write-5310/. I know hundreds of companies (most mid-size, yes) who have avoided the need to ever build a data warehouse by deploying QlikView. And yes, in (typically) larger companies QlikView is a fantastic vehicle for the "information delivery" or "last mile" of a data warehouse architecture. Can you say *poof* to indexing, cube building, data mart building, aggregations and summarization for the most part, etc.? In a given situation, there may be valid technical or business drivers for a data warehouse, regardless of the presence of QlikView. If so, build it or use it. If not, I see no reason to race to build one. And believe me, we build them all the time for clients. The existence of QlikView in a company doesn't limit one in any way to build one later if your situation changes, either. Interesting conversation and this is the subject of an upcoming blog I’ve written for our website. The data world is not a tidy place, and there’s no tidy answer to this. For everyone who asserts you always need a data warehouse, I can (and have) found IT folks who will concede that the majority of data warehouse implementations fail to deliver the business value anticipated or expected when they were started. But I would never use that fact to assert one shouldn’t bother with a warehouse.

I CAN point to folks replacing their data warehouse with QlikView (I did at Pergo) or this gentleman: http://histalk2.com/2010/05/03/readers-write-5310/. I know hundreds of companies (most mid-size, yes) who have avoided the need to ever build a data warehouse by deploying QlikView. And yes, in (typically) larger companies QlikView is a fantastic vehicle for the “information delivery” or “last mile” of a data warehouse architecture. Can you say *poof* to indexing, cube building, data mart building, aggregations and summarization for the most part, etc.?

In a given situation, there may be valid technical or business drivers for a data warehouse, regardless of the presence of QlikView. If so, build it or use it. If not, I see no reason to race to build one. And believe me, we build them all the time for clients. The existence of QlikView in a company doesn’t limit one in any way to build one later if your situation changes, either.

]]> Comment on How To: Qlikview 9 server with IIS Windows 2003 by william http://www.quickqlearqool.nl/?p=1012&cpage=1#comment-3885 william Tue, 06 Jul 2010 17:14:24 +0000 http://www.quickqlearqool.nl/?p=1012#comment-3885 Hi Francois, Depends whether you want to host more websites besides Qlikview on the machine.. If you do, you need the IIS webserver. For basic installations I would definitely go for the Qlikview built in webserver. If you want to have more control (security etc), go for IIS. However, most installations I'm using the Qlikview webserver.. very easy to intstall.. up and running in just a few qliks ;-) Hi Francois,

Depends whether you want to host more websites besides Qlikview on the machine.. If you do, you need the IIS webserver.

For basic installations I would definitely go for the Qlikview built in webserver. If you want to have more control (security etc), go for IIS. However, most installations I’m using the Qlikview webserver.. very easy to intstall.. up and running in just a few qliks ;-)

]]>