A programmers whose job is to make these kinds of reports will already have information about postcodes and so on, and take less time than you. Tableau is quick at doing simple things, but takes a lot of learning to do complex things. Often, you will have to resort to custom scripts, creating views, etc. Often, it just won't have the ability to do certain things.
Anyone with any experience in drag and drop applications will tell you that once things get complex, it ends up taking much more time using the simple drag and drop solution as you spend all of your time trying to get it to do something that is outside of a basic drag and drop model.
You say "will already have information about postcodes and so on". How exactly do you get your hands on postal code geo data, have you tried that? Have you created your own geo postal code database, or maybe used an API. I'm talking international postal codes too.
I have, and I can tell you it's not easy, for example in Canada there are like over 10k postal code regions. Then imagine maintaining this dataset, no thanks.
Anyhow that's not the point, that's just one data set Tableau does very fast, but tomorrow could be something totally different and the next day, etc.
Sure for complex custom requirements no BI tool will work, but it's sure better than what people were doing just a few years ago with excel or hiring expensive firms.
Are the complex requests in regards to getting/manipulating the data, or in the final visualization. I'm trying to build a desktop tool similar to Tableau but with the ability to easily drop down into python and do data manipulation with the pydata stack. Intended audience is the new breed of quantitative analysts/data scientists.
Both. While tableau has a visual query builder, sometimes the queries are too complex. For example they may need self-joins, non-standard join criteria, temporary tables, etc. So ultimately, the tableau guy has to ask a programmer or database person to create a script to use as the tableau source.
One example that involves both is when the visualisation needs a contiguous date range in the data, but the data is missing some dates. As a programmer it is easy to just loop through a date range and put 0 where there is no data.
There are also lots of limitations in terms of the visualisations. The end result was that multiple visualisations had to be created to show something that a programmer would be able to create as one visualisation.
I would say mainly visuals, think Photoshop meets Excel meets Javascript. One of the founders of Tableau founded Pixar studios so you can imagine that graphics are important. But it also has some great data options.
Except that it only lets you do a set number of things. Most requests for information are not simple, and once you leave the comfort of simplicity, you have to become an expert in tableau, or in many cases, just accept that it can't do what you want it to do.
Unless your queries are very simple, you are better off finding a programmer and asking them to do your job.
In other words, it is for big shitty companies that have hired a bunch of useless people who can't do anything and need reports to get their bosses off their back.
I used to work at a company where, under duress, I had to push tableau to its limits. My company spent hundreds of thousands of dollars on it. The main use was to provide reports on the data created by the application we sold.
It would be great if it just stayed as a better version of the excel chart maker. Instead, it was seen in my company as a way to replace programmers. All of these types of applications have the same flaws:
They sell a dream that you can turn a complex task that requires experts, into a simple task that anyone can do. In reality, you either have a simple application that doesn't do much, or an extremely complex application that still doesn't offer the performance and flexibility of just using an expert.
You end up creating a programming via drag and drop application that is more complicated to learn than actual programming. You replace general programmers with useless tableau specialists.
It took the tableau experts weeks to do what a programmer could do in days when complex requirements came up. Most requirements were complex.
Tableau Server is very, very slow and requires massive resources to run.
Tableau had to run the full, unfiltered query so that it could generate filter lists with all of the possible options. This query was often too large to run.
Anyone with any experience in drag and drop applications will tell you that once things get complex, it ends up taking much more time using the simple drag and drop solution as you spend all of your time trying to get it to do something that is outside of a basic drag and drop model.