Programming

18180 readers

7 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

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 !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Beyond Foreign Keys (lackofimagination.org)

submitted 10 months ago* (last edited 10 months ago) by Aijan@programming.dev to c/programming@programming.dev

9 comments fedilink hide all child comments

In a relational database, foreign keys are normally used to associate records stored in different tables, but wouldn’t it be nice to define relationships dynamically without having to add extra columns or tables? And while we’re at it, how about having sparse relationships by associating a record directly with any other record like “post X was last edited by user #123” or “post X was flagged for review by user #456” (who happens to be a moderator)?

top 9 comments

sorted by: hot top controversial new old

[–] Kache@lemm.ee 9 points 10 months ago (1 children)

So... a polymorphic many-to-many join table?

[–] Aijan@programming.dev 3 points 10 months ago (2 children)

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"
}

[–] Kache@lemm.ee 6 points 10 months ago* (last edited 10 months ago) (1 children)

Fine for prototyping, but adds a scaling tech debt "time bomb" for a live system. Those associations had better be really sparse.

[–] Aijan@programming.dev 2 points 10 months ago

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.

[–] jkrtn@lemmy.ml 4 points 10 months ago (2 children)

Don't you want a graph database at this point?

[–] Aijan@programming.dev 3 points 10 months ago* (last edited 10 months ago)

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.

[–] mvirts@lemmy.world 2 points 10 months ago

i was thinking the same thing

[–] solrize@lemmy.world 7 points 10 months ago (1 children)

NoSQL has been a thing since before there was SQL.

[–] Aijan@programming.dev 3 points 10 months ago

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.