Jonathan Philippou
2
Full-Stack Dev -> Data Eng... dbt/Data Modeling is hard. Guidance?
Full-Stack Dev -> Data Eng... dbt/Data Modeling is hard. Guidance?
Hey guys,
I'm a Full Stack Dev switching to Data Eng.
I am stuck on dbt + Data Modeling.
Idk how to solve simple problems from a Data Modeling approach.
Like... something as simple as "revenue" gives me trouble.
If my initial DB has these tables, how might I design a "star schema" for the purposes of revenue?
  • Sales (refs a Product and a Customer)
  • Expenses
  • Products
  • Customers
I'd want to support things like...
  • Daily, Weekly, Monthly Revenue, etc (this is called the "Date Dimension"?)
  • Revenue by Customer, or product (customer/product dimensions?)
  • Advanced stuff (like Profit, Rev growth, etc... but all capable of applying the above dimensions as well)
How would such a Schema be designed?
Is "star schema" the way to go?
What would normally be consider the most "granular" in such a case?
"Sales"? or a new "Revenue" model.
What does a "Revenue" model even look like?
Am I even allowed to do that?
Does that even make sense?
Like... although it'd be very nice to have such a model, idk how it'd get attached to any of the dimensions.
Is a "star schema" even the way to go?
And... aside from my specific example... are there any general rules, tips, best practices that come to mind while reading that anyone can share to help me learn?
From Full-stack / backend dev, Schema design was always about coming up with those initial tables, and I'd solve problems using typical coding (functions, algorithms, etc).
This way with Data Eng feels new and different.
I imagine other's making the Full-stack -> Data transition might also run into similar issues.
Any insights to helping ppl in my position stuck on these types of problems would def be appreciated.
Thanks!
1
2 comments
A community of data professionals building architectures with modern tools & strategies.
Leaderboard (30-day)
powered by