In our WMS system (relational database) we have a link from Department(50 records) à Category(200) à Subcategory(600) à Product(30000). 2 of these tables only have 4 fields on them. My question is should I just leave QlikView join them automatically by the WMS link, this is done without creating any synthetic links, or should I manually join them when I read them into QlikView to create one table ? Are there any performance issues relating to each solution I should be considering ?
For me, I tend to keep the tables separate. I create QVDs for each table and then join them up when loading into my app. This could simply be because I'm used to using relational databases and that's how they work.
I've heard a lot of mentions of joining everything into one table and that is probably a fine way to handle it.
In your case, I'm not sure if there would be a big difference. Users on this forum have reported having tens of millions of rows in single tables of their applications and having them work fine. I'm guessing that if you joined everything into one table you would be at less than 2 million.
I'm trying to come up with a definitive advantage to one or the other, but I don't think it matters much to QlikView. Perhaps one of the other users has some quantitative evidence of one being faster or more effecient than the other.
I'd say that with those (relatively small) data volumes, performance wouldn't be an issue either way. You can do it the most convenient and intuitive way for you and your developers and users. When performance is not an issue, simplicity and ease of use should be your best guiding principles.
For me, I tend to keep the tables separate. I create QVDs for each table and then join them up when loading into my app. This could simply be because I'm used to using relational databases and that's how they work.
I've heard a lot of mentions of joining everything into one table and that is probably a fine way to handle it.
In your case, I'm not sure if there would be a big difference. Users on this forum have reported having tens of millions of rows in single tables of their applications and having them work fine. I'm guessing that if you joined everything into one table you would be at less than 2 million.
I'm trying to come up with a definitive advantage to one or the other, but I don't think it matters much to QlikView. Perhaps one of the other users has some quantitative evidence of one being faster or more effecient than the other.
Thanks both for your reply, as I do most of my work as a Relational Database programmer I find it easier to think of things in that way, if there are no large overheads that people know of I will carry on creating the separate QVD's.
Yeah, QlikView deals just fine with a highly-normalized relational database structure, so if that's what you're used to, you might as well stick with it. I have the same sort of background, so I started out with highly-normalized tables in QlikView, but over time drifted to more of a reporting structure with massaged, denormalized data. But I don't think it's a big deal either way.
