EDITOR’S NOTE 2018-05-17: At the current time, it has been determined that the CONTAINS() solution below performs very poorly in the Hyper extract system in all releases of Tableau 10.5 and the 2018.1.0 release. The performance issues have been corrected in the 2018.1.1 release, but will not appear in any version of 10.5. If you are currently using it in a pre-10.5 version of Tableau, please only upgrade to 2018.1.1 and after.
In Part Two of the series (see Part One here), we’ll go through two solutions to Row Level Security that are a bit more programmatic and require some work outside of just Tableau Desktop calculations, but our often the recommended solution due to their speed and flexibility.
Matt Miller works at Tableau as a sales engineer along with Bryant. He’s guest posting this excellent set of articles, with hopefully more to come.
Note: If you are looking at enterprise-level scaling with extracts, skip right to Part 2, then come back to read the background.
A wise man who runs a well-respected Tableau blog once wrote:
“To be secure and perform well, you must use a Live Connection to your database. Extracts will be too large if you join a security table that is one-to-many to your data table (we say they “blow up” to dissuade people).”
What happens when a live connection is less than desirable for a use case, or downright impossible? Are we to let our Tableau Server users swim in a sea of insecure extracts (‘Do my columns look wide in this?’) ? Certainly not. The methods used to secure extracts differ from most currently published Row Level Security setups or walk-throughs, as the design is centered around minimizing duplication of rows to ensure performance in both creating and using them.
Since my education in uncountable infinite sets ended in undergrad, this blog won’t try to cover every niche business logic and data security use case, but instead provide ideas and tools to take back you your own environment and mold to your needs.