So... a polymorphic many-to-many join table?
this post was submitted on 11 Apr 2024
15 points (89.5% liked)
Programming
17431 readers
83 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
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.