Can I use QLIK as database itself or it is only a front end tool that pulls data from other DBs?

[#1]

We don't have DB, we save our data into excel which is not preferable so we are looking for a an alternative, so for reporting, QLIK is really helpful, but I am wondering if we can use it as a back-end repository.

[yura_ratu]

Hi Hanan,

You can store all historical data from all your files into QVD files using Qlikview applications without any UI, and then pull only data you need in actual reports

[#3]

So in this sense, we can use QLIK as Database repository, what I mean, can we create relational tables and such this stuff. I do really ask as it concerns me working on excel. One more question, technically, is it recommended to use QLIK as database + front end tool or only front end and connect through ODBC to SQL server. Is there any limitations using QLIK as database long term thinking.

[ashfaq_haseeb]

Hi,

It really depends on what is your exact requirement.

There are many ways available to use qlik to write back to databases as well.

Its better use Qlik as D.A.R (Dashboard Analysis and Reporting) tool.

Regards

ASHFAQ

[#5]

What I think about is as follows:

I really need to build a robust schema to be shared with other companies, and this schema will not only be used for reporting, I think we want to use it to create GIS maps using either QGIS or ArcGIS, not sure if QVD files can be recognized by each of these.

Technical wise, I do lean to separate DBs from front end tools, however I would be open to any new ideas or thoughts especially, I'm not a QLIK prof.

[ashfaq_haseeb]

Yes,

Qvd can store your mapping data and you can isolate it from DB.

But for the one whom you are sharing this QlikView file requires a license to open this.

Regards

ASHFAQ

[datanibbler · Accepted solution]

Hi Hanan,

I was kind of doing something similar at the moment - using QlikView (qvd files) as a database, but it's only going to be used in our company.

Strictly speaking, of course QlikView is not a database tool. Data storage in itself is not a problem - we use QlikView to build up histories of tables in our DB  that for any reason are not historized. That works very well.

The qvd files you can generate are flat files and not connected to each other - different qvd files may be connected the moment you load them into a datamodel.

I have no experience yet rgd. the volume of data that can be handled in this way. Since qlikView is not optimized for this type of use, it may well be that performance will suffer with large volumes of data.

Sorry I cannot say any more about it, I have no experience. You will have to try it out.

Best regards,

DataNibbler

[#8]

Your input is such a tremendous help! We have large amount of data (ODK forms) that have to be assembled, and the old files have to be archived as well, so using QLIK as database will have many limitations: as stated license, performance issues, and so forth. I always lean to separate data source from front end tools.

Thanks!

[datanibbler]

Hi Hanan,

well, like I said I have no experience, but following the general rule to always use the right tool for every work, given you already know you'll have a lot of data and so forth, I would not recommend using QlikView as database.

Especially if it's going to be used by several companies, you are likely to run into problems along the way - and fixing all the problems as you go is going to be quite as expensive (or more) as paying for a real database system.

You can still use QlikView for reporting out of the database, but as database - I really think the limitations and the potential for problems outweighs the advantages - I would have argued against that here, but that decision was made  by one person months ago, I build it in QlikView, it would work fine for a start - and I'm still waiting for a management_decision on the issue of whether or not to purchase the necessary licenses 😉

HTH

[#10]

I fully understand what you are going through. Actually, we think to buy a license to use QLIK as reporting tool only, but as data source, sure it will have many limitations, as it is hard to integrate this with other tools you might use in the future, so long term thinking, we need to create our own DB separated from any front end.

Creating DB from scratch might be time-consuming, but this will overcome any future limitations for enhancements or development. I really was looking for such an answer rather than go and use it.

Bunch of thanks!