Second, understanding that neither are true “enterprise” plays like Cognos/IBM, Oracle,SAP/Business Objects, etc. can these SME (small-medium enterprise) focused companies compete successfully against the big boys or is it simply a matter of time before the big boys start to focus on the small-mid sized customer and either put these guys out of business or acquire them outright.

Thanks

QlikView offers some cool UI features rare or missing in other BI products’. But it also is missing some that other products have. So speeds-and-feeds matter a lot — not so much directly, but rather due to their effect on deployment and management hassle. (Great speed w/o much administrative effort means — well, it means that you don’t have to put in much administrative effort.)

So yes, architecture DOES matter.

By the way — congrats on getting on the QlikView horse impressively early.

CAM

iLuminate has not, historically, been too active outside of Spain. There’s little reason for you to have heard of them if you don’t happen to do work there.

CAM

Though QlikView is being dragged into the Enterprise market because it’s really good at rapid design, test and rollout, QlikTech has stated over and over that they want to move broader, not higher, in the market. So they focus on collaboration features and Microsoft Office integration, for example.

Performance gains have come from immediate adoption of 64-bit and parallel calculation of report elements on multi-core machines. In the 7 years that I’ve been working with the product and the 4-5 years that I’ve attended the user conferences, no one has complained about the speed of the database. Satisfaction levels among customers is through the roof.

So, if you are analyzing for the enterprise market (and QlikView has had big success stories there) then QlikView is quickly eliminated from terabyte plays. In the mid-size, small-business or enterprise-division markets, it is still impossible to evaluate QlikView the database without QlikView the frontend. And that’s not to mention QlikView the ETL tool.

Re “The associative aspect is really more meaningful in describing the end user experience, in that you see visually what is associated and is not associated with any particular selection or drilldown.”

Thank you for admitting that clearly!!! It wastes a fair amount of analysts’ time when your company pretends otherwise.

Not explaining your technology is a legitimate business decision. (And your financial results suggest that, for now, it’s been a successful choice.) Pretending to be explaining technology when you’re not, however, is needlessly annoying.

That said, I would caution you that the choice not to explain will probably not always seem to be as happy a one as it is today. Pretending that your technology is more exotic or innovative than it really is can pay dividends for a while. But I think you’ll learn that it has downside too.

CAM

After a good night’s sleep, I was going to add this morning that what I’m calling “pointers” are actually quite similar to a join index, but you have beaten me to the punch with your comment about star index pre-joins. Either way, the critical distinction is between joins that are executed at the time of the query, and joins/pointers that are executed in advance and stored with the data. Clearly QlikView does the latter, and that is what gives it great speed.

As to the data expansion, it was on disk before it was in memory. It’s the disk file that may be 1/10th the size of the original data. The compression in QlikView comes primarily from tokenization (that is, if the same string occurs many times, QlikView stores the actual value just once). Apparently, QlikView returns the data to its original format when it loads it back into memory.

illuminate definitely is a different technology from QlikView. See my own post on the topic at http://customerexperiencematrix.blogspot.com/2008/04/illuminate-systems-iluminate-may-be.html. I purposely didn’t mention the illuminate/QlikView connection because it only confuses matters. But, since you brought it up, you should realize that the relationship is technically limited: illuminate exports a data set that is then loaded into a QlikView database, and QlikView reports against it. That is, QlikView does not query the illuminate database directly.

I empathize with your desire to fit QlikView into familiar categories, but try to resist. It’s not a columnar or inverted index system. The salient performance characteristics of those technologies are that response time increases (a) when you add more columns (because you have to read more data) and (b) when you add more joins (because processing is required). Neither of those parameters increases response time in QlikView so far as I’ve ever noticed. What does increase response time is calculations within reports, but that’s another topic entirely…

The other point I had intended to add to yesterday’s comment was a clarification about how QlikView joins differ from SQL joins. QlikView reads the data “in place”, rather than creating a result set like SQL. The specific advantage comes with many-to-many joins. Imagine two tables with three rows, each having the same key value. A traditional SQL join would create nine rows in the result set: that is, you get three records from matching the first record in table A with all three records in table B; another three from matching the second record in table A against all of table B, and yet another three from matching the third record in table A against table B. This means that if you, say, added the values from table B records, they would be triple-counted. QlikView would recognize that the records all match, but still reads table B directly. Therefore no redundant records are created, and a sum of fields from table B would be correct. Better still, a report that showed the sum data from table A and the sum of data from table B would give the correct answer regardless of whether you had selected one, two or three rows from table A.

(Apologies if this is too abstract. One practical example is calculating response rates to a promotion. Table A has each response, and table B has a single record with the audience quantity. If you do a SQL join of table A to table B, all the records in table A match table B, so the result set has one record for each response, and every record has the audience quantity on it. Calculating response rate by dividing the sum of the responses into the sum of the audience quantities would therefore give the wrong result. This doesn’t happen in QlikView.)

David