Qlik Community

Ask a Question

QlikView App Dev

Discussion Board for collaboration related to QlikView App Development.

Announcements
On May 18th at 10AM EDT we will answer your QlikView questions live. REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
ramonarcusa36
Contributor III
Contributor III

Document size after changing model

Hey guys.

There is something I don't understand. My model consists of one big fact table (around 40 million rows) and approximately 20 dimension tables (products, customers, all those things).

I have made a slight change in my model: I have left joined my fact table to some simple dimension tables. I got a recommendation telling me it's usually a better practice to include the descriptions in the fact table, so I tried. And contrary to what I expected, my document size has decreased a lot! From 3 GB to 1.6 GB.

Is this normal? What is QlikView doing here that results in reducing the file size after including text descriptions in a big fact table? Shouldn't it increase its size because long descriptions are now repeated many times?

Thanks!

11 Replies
oknotsen
Master III
Master III

In contrary to common belief does Qlik not store the data de-normalized, so those text descriptions still get stored once.

Some space will be gained because the key field between that fact and dimension table is now removed, but this huge difference is not explained that way.

May you live in interesting times!
avinashelite

Check your Joins once ...it might be creating lot of junk data or duplicating data because of which the data size is getting increased ....

Digvijay_Singh
Master III
Master III

Its strange that size is reduced, can you check the information density of the key field for which dimensione table is joined, also normally dimension tables are pretty small but you can confirm the size of dim table being joined into fact table.

manucamon
Specialist III
Specialist III

Hi ramon,

That is because some dims duplicate some values. If you wanna add descriptions to fact tables it is better use Applymap.

But, for app performance is better an Star Model or Snowflake Model.

Kind regards.

marcus_sommer
MVP & Luminary
MVP & Luminary

Are there further changes within the application maybe by the compression-settings? Otherwise elaborate a bit more the changes between your tables (number of records, kind of keys and so on) and also if all data are available (this meant, if the left joins were not completely successfully there could data be removed).

- Marcus

oknotsen
Master III
Master III

Manuel Capella wrote:

for app performance is better an Star Model or Snowflake Model.

This depends on your data and partly your hardware.

I can't imaging a Snowflake model to ever be faster (but that might be my lack of experience with those). A star model CAN be faster than a single table model. It can also be slower.

May you live in interesting times!
manucamon
Specialist III
Specialist III

I have used ever snowflake and star models, these models ever worked fine than single table for me.

sujeetsingh
Master III
Master III

seems your joins worked or reduced repetiton or redundancy .

oknotsen
Master III
Master III

There is a difference between "fine" and "have the best performance" .

May you live in interesting times!