Redundant vs. interdependent vs. row-level slice r...

dbaum · 07-30-2022 08:49 AM

I have a table with several slices used for different purposes. Many of the slices are tiered in the sense that each references successively more stringent filter criteria. I wonder whether there's an optimal approach to defining the row filter conditions in terms of:

Repeating the verbatim conditions across slices vs.
Directly referencing less stringent slices in more stringent slices vs.
Pushing the conditions explicitly down to each row and referencing those

Any guidance regarding benefits or drawbacks (e.g., app performance or anything else) of each of the approaches is appreciated. Examples follow.

Note: For purposes of these examples, I simplified representation of the filter criteria to basic [Criterion X] columns. In reality, each of the AND functions' arguments in the examples is typically more complex than just a reference to a single boolean column from the slice's table--i.e., they use functions like IF, derefs to parent values like [Parent ID].[Parent Table Column], comparisons to values in other tables like [User ID] = INDEX(Current User[User ID], 1), etc.

Redundant approach

SliceA row filter condition

AND(
  [Criterion 1], 
  [Criterion 2]
)

SliceB row filter condition

AND(
  [Criterion 1], 
  [Criterion 2], 
  [Criterion 3], 
  [Criterion 4]
)

SliceC row filter condition

AND(
  [Criterion 1], 
  [Criterion 2], 
  [Criterion 3], 
  [Criterion 4], 
  [Criterion 5], 
  [Criterion 6]
)

Interdependent approach

SliceA row filter condition

AND(
  [Criterion 1], 
  [Criterion 2]
)

SliceB row filter condition

AND(
  IN([ID], SliceA[ID]), 
  [Criterion 3], 
  [Criterion 4]
)

SliceC row filter condition

AND(
  IN([ID], SliceB[ID]), 
  [Criterion 5], 
  [Criterion 6]
)

Row-level approach

[InSliceA] virtual column app formula

AND(
  [Criterion 1], 
  [Criterion 2]
)

[InSliceB] virtual column app formula

AND(
  [InSliceA], 
  [Criterion 3], 
  [Criterion 4]
)

[InSliceC] virtual column app formula

AND(
  [InSliceB], 
  [Criterion 5], 
  [Criterion 6]
)

SliceA row filter condition

[InSliceA]

SliceB row filter condition

[InSliceB]

SliceC row filter condition

[InSliceC]

MultiTech

I'm not sure what you mean by "using a VC" - like.... have a column in your table with a formula, then based on that formula it's held inside a slice?

--------------------------------------------------------------------------------------------------------------------

Generally... in my production apps I'll have a combination of both.

I'll have a VC with an algorithmic-formula to create an [Auto_Status] column
I'll then have slices hold those various "buckets" (ongoing, completed, scheduled) for ease of reference later.
Then sometimes, I'll have secondary slices looking at the first... which is looking at a VC.

------------------------------------------------------------------------------------------

Any time you can reduce the redundancy is good, helps reduce possible copy/paste errors.

But dependence makes parallel processing slower

Because now that slice has to wait for the first slice to finish
Only once the first one has it's complete answer can the second slice then move forward

So when you introduce dependences like this, you can run into slow-downs depending on how your system is built.

dbaum

@MultiTech wrote:
I'm not sure what you mean by "using a VC" - like.... have a column in your table with a formula, then based on that formula it's held inside a slice?

Yes, exactly. That's what I tried to illustrate in the original post's "Row-level approach" examples of virtual column expressions and slice row filter condition expressions.

@MultiTech wrote:
But dependence makes parallel processing slower

Thanks for pointing that out. Sounds like an important point to keep in mind. The benefits of using interdependent slices to avoid redundancy may be of fixed magnitude (e.g., efficiency for the app creator in defining slices), while the costs may be proportional to the app's scale (e.g., inefficiency for app users since interdependent slices must be processed serially rather than in parallel--and that inefficiency would grow as table rows increase).

MultiTech

I'd be curious to hear what a dev has to say on the matter?

If we simplify the question to:

What's better in the big picture:
1. creating dependence in slices, or
2. redundantly copying criteria into secondary slices?"

Include a primary slice in secondary slices??? (creating dependance)

@dbaum wrote:

AND(
  IN([ID], SliceA[ID]), 
  [Criterion 3], 
  [Criterion 4]
)

or simply repeat the criteria in sliceA into the secondary slice?

@dbaum wrote:
AND(
[Criterion 1],
[Criterion 2],
[Criterion 3],
[Criterion 4]
)

--------------------------------------------------------------------------------------------------------------

@Adam-google

dbaum

@MultiTech wrote:
curious to hear what a dev has to say on the matter?

Yes, I'd also be interested in further advice and perspectives.

Redundant vs. interdependent vs. row-level slice row filter conditions