In general OBT (or what I prefer OBFT) doesn't scale well. What you have is a data model for each front end. A simple change would require a reorg of OBFT whereas star schema you're just adding a dimension attribute. You can always build OBFT from a star schema but the reverse is more difficult.
Preach! Correct on all points. The only thing I would add is that even if you build a great dimensional model and train internal staff to maintain it, it's still a tall order to keep your Kimball warehouse healthy for a significant length of time. It's like a person buying a Ferrari but not driving it much because the maintenance is too expensive. 🤷♂️
we tried star schema's for about a year and it ended up being a disaster to maintain. we're a small group that supports a lot of users across many subject areas. Trying to create a star schema for different subject areas was overkill and we wasted so much time and got nothing done. one big table is the way to go.
I must say the OBT is great when you're analytics business requirements / data use case is small. In other cases this structure is inflexible for different use cases. What will happen is your business owners will start to build their own data models/queries inside the visual tool (loocker/power bi) instead of just pull it from the data model. These tools can't always contain so many processes, especially since there are duplications in data retrieval.
I'm finding we can catch more and more use cases with OBT, but your point is still valid. I think we need to live with the fact that OBT can simplify tons of use cases for downstream consumers, but will make others more complex. In those cases, I think it's best to let them access the dimensional models the OBT is built from. Thoughts?
Hey, I love your channel Quite frankly, this is the only BS free channel I have ever seen about data engineer Would you mind If I was your remote personal assistant. I would help you do the things you would do every day for free. It would be my honor to work with you
YES! one big table is the way to go. Although its probably good practice not to stuff too much into one table. We use the one big table approach but its mostly subject driven. The star schema approach would take way too long to design and troubleshoot. its useless to my team.
In general OBT (or what I prefer OBFT) doesn't scale well. What you have is a data model for each front end. A simple change would require a reorg of OBFT whereas star schema you're just adding a dimension attribute. You can always build OBFT from a star schema but the reverse is more difficult.
Preach! Correct on all points. The only thing I would add is that even if you build a great dimensional model and train internal staff to maintain it, it's still a tall order to keep your Kimball warehouse healthy for a significant length of time. It's like a person buying a Ferrari but not driving it much because the maintenance is too expensive. 🤷♂️
we tried star schema's for about a year and it ended up being a disaster to maintain. we're a small group that supports a lot of users across many subject areas. Trying to create a star schema for different subject areas was overkill and we wasted so much time and got nothing done. one big table is the way to go.
2:00 Using a dimensional model to build OBT May be okay, but seems that analysts should build this via pivot table query instead of data team.
I must say the OBT is great when you're analytics business requirements / data use case is small.
In other cases this structure is inflexible for different use cases.
What will happen is your business owners will start to build their own data models/queries inside the visual tool (loocker/power bi) instead of just pull it from the data model.
These tools can't always contain so many processes, especially since there are duplications in data retrieval.
I'm finding we can catch more and more use cases with OBT, but your point is still valid. I think we need to live with the fact that OBT can simplify tons of use cases for downstream consumers, but will make others more complex. In those cases, I think it's best to let them access the dimensional models the OBT is built from. Thoughts?
I like OBAT more (one big ass table)
Great content…
I think one big table is for the operational environment.
Hey, I love your channel
Quite frankly, this is the only BS free channel I have ever seen about data engineer
Would you mind If I was your remote personal assistant. I would help you do the things you would do every day for free. It would be my honor to work with you
YES! one big table is the way to go. Although its probably good practice not to stuff too much into one table. We use the one big table approach but its mostly subject driven. The star schema approach would take way too long to design and troubleshoot. its useless to my team.