Clojurians Log v2

Hey Tobias, I'm not sure if I follow. What do you mean by "two independent entities cannot be directly associated in a Datom"? Datoms are eavt tuples; Are you talking about what cardinality? Could you share an example with me what you are trying to model?

Consider the example of a Person and a Concert. Both are independent entities. According to the modeling rule, these entities cannot be directly connected in a Datom. Instead, they must be indirectly linked through an intermediate Participation entity, which serves as a reified relationship.

I consciously violate that rule in Datomic by default. Only under very rare circumstances is a "join table"-like entity warranted -and that usually happens when the relationship itself has properties independent of either entity. e.g. Person A was the 12th person to buy a ticket to concert X.

Is that decision primarily based on the idea that it’s easy to change the structure later if you need to add properties to the relationship?

Yes. Very much so.

It is very liberatating to dispense with the SQL join table artifact and simply model relationships directly. I will note that in addition to the cases where the relationship ("edge") has properties of its own, the other scenario where I end up using something like a join table is when I need to model the temporal relationship between entities, e.g. "A owned X in 2022, now B owns C." Not being an expert in bitemporal databases, I suspect this is nicely modeled in that world without an explicit join entity but in Datomic I have introduced an "ownership" entity to model it.

If you wanted to associate data - like Role and Start Time - with a person’s involvement in a concert, would you then create a reified/join "participation" entity?

Talking about "independent" and "associative" entities feel like imposing a different (and less powerful) information model on Datomic's. "Independent entities" like Concert and Person are very slippery concepts and often lead to complected data models. I tend to prefer thinking about identities and relationships. In your example, it seems like the Participant concept is a key one. Another one could be Reservation depending on the kind of problem the application is helping to solve. Those concepts of Participant and Reservation have identities, we want to be able to think about their instances across time. They're not less "independent" than Concert or Person.

Good data modeling of course requires careful consideration of current use and likely future trends. Thankfully Datomic is pretty forgiving when it comes to evolving schema -especially when you let go of the propensity to "save" names. Be liberal in introducing new names when new semantics and use cases come along and keep the old names meaning exactly what they meant at introduction. Particularly on the subject of identity, this can be a shockingly complex topic so be prepared to evolve your data model as you (re-)consider the critical entities and identities of your application. I sometimes find comfort working from the outside in: if the whole world thinks of a Concert as a thing (and, conveniently, you can find externally authorities that assign identifiers), those are good candidates for stable entities in your app. But, to Benoit's point, that might not be enough and for the specific area where your business has found a niche, you probably need to think about "entifying" more subtle concepts (`Ownership`, Participation`, Reservation, etc). Time is only one attribute of a relationship (albeit a common one) that might push you to modeling the relationship as an identity itself. A classic example in the Datomic world is some kind of (non-temporal) ordering on the relationship.

If you are interested in going really really deep into the concepts of entification and identity, https://www.rogerclarke.com/ID/IDM-Bled.html has always struck me as being well-founded. <- BEWARE, this is a rabbit hole.

Perhaps https://datomic.narkive.com/Rn7jWmvv/modelling-a-graph-using-reified-transactions, which was recently helpful to me, would also be useful for you. The short answer to your question is probably, "Sometimes but not always."

Maybe ”associative entity” is a better term than ”reification entity”…