Hey @Frosty,
What do you mean by UX Repository?
I see that you seem to have one base per department. Having such “independent” bases might be needed depending on the size of the business, and on other factors, but unless we have really good reasons for handling in that way, I usually suggest having data as consolidated as possible under just one centralized base which will work as your unique source of truth!
If you share some more context I can probably help you out!
Mike, Consultant @ Automatic Nation
Yeah, as Mike said, need a bit more detail on what you’re thinking. When I hear UX Repository, my mind goes to user experience tickets or something, but then you said data repository for all department and that makes me think backups or for a dashboard/reporting build.
I kind of disagree with Mike, I do think there’s more value in creating separated bases for specific departments/functions, as the data supporting your supply chain is wildly different from HR (and then you’d end up with one mega-base with like 100 tables) but as he said it depends on size and scale for sure.
Of course, there’s base syncs, which I think is how many of these multi-base schemas deliver data to the top level stakeholders. Conceptually you add a summary table to each base with whatever information needed for high level reporting (to the C-suite or whoever) and then sync each of those summary tables into your company data base. Then HR can have 6 tables with their relevant data, and 1 table that sums up activity, and that last table is replicated in the Company Data Base.