So… a polymorphic many-to-many join table?
Yes, that’s correct. Here’s how an entry in the join table looks like:
{ "id": 6, "sourceComp": "user", "sourceId": 2, "targetComp": "post", "targetId": 3, "type": "author", "createdAt": "2024-03-28T13:28:59.175Z", "updatedAt": "2024-03-28T13:28:59.175Z" }Fine for prototyping, but adds a scaling tech debt “time bomb” for a live system. Those associations had better be really sparse.
There’s certainly the danger of creating too many ad-hoc or sparse relationships, which can cause issues. That said, when used for supplementing foreign keys, Tie-in can be a useful tool in a production system as well.
Don’t you want a graph database at this point?
That idea crossed my mind too, but you can’t really use the full capabilities of SQL in graph databases, and that’s a deal breaker for me.
i was thinking the same thing
NoSQL has been a thing since before there was SQL.
AFAIK, no NoSQL database fully supports SQL, and only some offer support for transactions and joins. The idea here is to augment a relational database by adding capabilities for dynamic relationships.