[sschnei8]

I love a semantic layer as much as the next guy...

Pivoting a decent sized BI shop toward using one instead of splashing the same SQL all over the place is *tough*. It's one of those: "the analyst could have been building important report for director and you want them to create re-usable logic??? we'll do that later, get report done now. Just copy/paste that SQL over here"

This is how you end up with the the 1000 model, "the numbers don't match up", hot mess situations that gain momentum and are hard to slow down.

[halfcat]

The flip side is, you often don’t know what needs to be reusable until you’ve had some iterations. Wrong abstractions can be way worse, and also gain their own momentum.

[dietr1ch]

The problem is that often these quick or maybe not reusable are written in such a haste that there's no breadcrumbs left to do the right thing whenever you are done getting that urgent thing out (most likely never because "everything is urgent" :( )

[efromvt]

Yeah, minimizing the gap between the semantic layer authoring and adhoc is what you need to do to close that - there has to be a progressive model both for consumption (take this semantic layer, slightly extend/tweak it in an adhoc fashion) and for organically promoting up the adhoc works to the layer.

Right now a lot of semantic tools introduce a big discontinuity in both workflows that keeps the two worlds separate.

[anon84873628]

That tracks. The semantic layer is like a capital investment that pays off over time. So it can be hard to justify the initial investment if people don't grok the payoff.

[mritchie712]

this is why I liked Looker. The only way to build reports was from the semantic layer which was easy to use and built into the BI.

we took the same approach when we started https://www.definite.app/.

[secondrow]

This is why I liked BusinessObjects