Fork me on GitHub

In episode 22, @nate and @neumann talk about using “flat data structures” and “namespaces keys,” instead of nested data structures. That concept is a bit unclear to me. Does anyone know of a paper or blog post which goes more in depth on this topic, with some code examples?


Hey @U01PE7630AC, I don't have any blog post links handy, but I do know we've discussed it a bit in this channel. Now that we have the full history searchable I was able to find some links to those discussions.


Jump to that message and look at the thread and other messages in the channel after.


I believe we also talk about namespacing keys in our Maps! Maps! Maps! episode:


That’s awesome! Thanks for digging those up, @nate!


I find that there is a lot of nuance to consider with regards to qualified keywords. In particular, context is very important. He touches upon that at .


For what it's worth, I've been using namespaced keys for over 3 years now and I still fine them useful in a number of situations. In particular, when I have to mix a number of fields together that come from other sources.


Eg. player, team, season, etc. You would have :player/id , :team/id, :season/id instead of :player-id, :team-id, :season-id, and such.


And definitely not the horror of:

{:player {:id 42}, :team {:id 11}, :season {:id 99}}


In general, the situation where I find them the most useful is when the map is a "bag" of fields from different entities that are all combined together for convenience or correlation (data that has be joined.)


You can do nifty stuff like this:

  (select-keys player [:player/id :player/name])
  (select-keys team [:team/id :team/name])
  (select-keys season [:season/id :season/year :season/phase]))


So that would be an expanded record of information about a player that would include more context: the team the player was on (at the time) and the related season.


@U01PE7630AC Let me know if that's helpful!

👍 1

@neumann Why is the nested data horrible though?