Thanks @tony.kay, that makes a lot of sense. So if I understand correctly, it is OK in Fulcro philosophy to have some data duplication, where stuff coming from the same backend SQL table can end up in different Fulcro component "tables" e.g. :report/by-id, report.alt/by-id. I assume this is a common pattern for BlaListItem and BlaDetail components? (<- this is incorrect, see comments downstream) I guess where my intuition was a bit off-mark is that there is no Fulcro DB equivalent of a table "select" where multiple components query different subsets of the same table, as this might lead to more "entanglement" and break local reasoning of components. (Am I thinking in the right direction here?)

@thomasmoerman What you describe is not what I would call duplication. Those two components are different UI concerns…they happen to need to share the same data, which is why idents exist: so you end up what that data normalized to the same place in your client db. It is perfectly fine and recommended for any number of components to have the same ident, which in fact should end up pulling data from the exact same thing on the back end and merging it to the same spot in the client db…it’s the same data, isn’t it? See the book’s comments in various places on how merge works and why.

particularly this (and sections around it): http://book.fulcrologic.com/#ResultMerge

If it is a “Bla”, then the table should reflect that…your intuition should be roughly correct on normalization coming from an SQL world: we don’t want the same fact in 2 places in the client db

NOTE: If you’re using Pathom (and you should be), use the table naming convention that is recommended there (e.g. :bla/id). The old /by-id convention came from an early suggestion in Om Next, and is no longer the recommended naming convention in general. It looks a little weird at first having idents like [:person/id 3] that are declared as (fn [] [:person/id (:person/id props)]), but that format allows Pathom to resolve ident-based queries nicely.