dbt-metabase VS corp

So how do we get this into Metabase? There's a tool called dbt-metabase that can infer Metabase semantic type information from the dbt schema and push it into Metabase- we run this whenever complete a dbt build, helping sync Metabase with whatever new fields we may have added.

Here's one that covers some of your points and that I like in general: https://github.com/dbt-labs/corp/blob/main/dbt_style_guide.md Except instead of prefixing my table names with the processing stage, I keep them in schemas by processing stage (source, staging, analytics). So, I can tell my analysts to look into the analytics schema for all the final tables, and they won't be bothered by intermediate models. The table names also have a precise structure that corresponds to our specific subject.

I find the content more or less ripped from of dbt's own styleguide

For anyone wondering this is the DBT style guide I am referencing from.

While the tool choice is obvious, how to use dbt is going to be a more controversial. There's a load of great resources on dbt best practices, but as you can see from my Slack questions, there's enough ambiguity to tie you up.

Just a slight critique, but I noticed some of the dbt models are a bit hard to read. Especially your dim_users SCD2 model, which uses lots of nested subqueries and multiple columns on the same line. You may want to refer to this style guide from dbt Labs. I find CTEs are a lot easier to parse and read.

I really like thisthis SQL STYLE GUIDE, and if you use dbt, the dbt style guide.

I like this one very much from dbt very much.

I recommend you write one. You can take inspiration from dbt's one or Gitlab

I've seen fishtown analytics coding conventions recommend a lot around here, but there are a few things about their recommendations of CTE use that confuse me.