Not a bad intuition to have. But with some reading you can learn that "db" refers to the in-app, in memory (or local storage) database, which is designed to hold all your application state, which allows it to be clearly transacted against and referenced from anywhere in your app.
You start writing pure functions which take the current "app-db" as an argument, and return what the "app-db" should be. If React is `v=f(s)` (view is a function of state), re-frame is `s=f(s,e)` (state is a function of the previous state, and events)
You know nothing about software architecture if you think that you can't optimize a software performance/responsiveness changing the way you store/normalize/retrieve data.
I know that I wouldn't want the choice of a fly-by-night front-end framework influencing how that's done with a back-end database. But, looks like I made the wrong assumption about the db structure that was influenced, I guess we have front-end databases now, which is an interesting idea I will be exploring furtherer.
You start writing pure functions which take the current "app-db" as an argument, and return what the "app-db" should be. If React is `v=f(s)` (view is a function of state), re-frame is `s=f(s,e)` (state is a function of the previous state, and events)