• 1 Post
  • 71 Comments
Joined 6 months ago
cake
Cake day: January 14th, 2024

help-circle















  • ResoluteCatnap@lemmy.mltoLinkedinLunatics@sh.itjust.worksBelching
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    14 days ago

    I think wed just need the following

    • rel.id (primary key)
    • rel.user_id (foreign key to person.id)
    • rel.user_id2 (foreign key to person.id)
    • rel.type (type of relationship)
    • rel.start (non null)
    • rel.end

    From there you don’t need a rel.status because you’re not updating this rel.id entry except for the rel.end. if they started dating again later it would be a whole new entry, and then you could query their entire dating history to see if they keep coming back to the same person, dating around, playing the field, etc. Separately there could be a friendship relationship that is tracked so you could if they ended being friends after a breakup.


  • To that point a person table with a relationship table. So this way you can reference relationship between two or more persons within the relationship table and that could be joined to the person table if needed. I don’t think you’d really be able to keep it within one table while exploring multiple relationships unless you’re storing a list of ids that is interpreted outside of sql. Also a relationship table would allow exploring other types of relationships such as exes, love interests, coworkers, family, friends, etc