One example could be to add a value to the relationship, like a rating or a ranking.

For example a Movie can be seen by many Users and a User can see many Movies. A user can rate the movie they’ve seen between 0 and 10. So, the join table would have 3 collumns:

• he FK for User
• the FK for Movie
• the numerical value of the rating by that particular User for that particualr Movie.

There is no concrete difference between the two options. But in general they will be similar. I think you are talking about these options:

struct Person;
struct Skill;

struct PersonSkills {
    person: PersonId,
    skill: SkillId,
}

vs

struct Person {
    skills: SkillId[],
}

struct Skill;

The main difference that I see is that there is a natural place to put data about this relationship with the “join table”.

struct PersonSkills {
    person: PersonId,
    skill: SkillId,
    acquired: Timestamp,
    experience: Duration,
}

You can still do this at in the second one, but you notice that you are basically heading towards an interleaved join table.

struct PersonSkills {
    skill: SkillId,
    acquired: Timestamp,
    experience: Duration,
}

struct Person {
    skills: PersonSkills[],
}

There are other less abstract concerns. Such as performance (are you always loading the list of skills, what if it is long) or correctness (if you delete a Person do you want to delete these relationships, it comes “for free” if they are stored on the Person) But which is better will depend on your use case.

It depends entirely on how you want to work with the data.

Have you considered sqlite? The database is just a single file, which gives you all the advantages of a text file (easy backup, sharing, easy editing via sqlite browser) while also providing the benefits of SQL when operating on the data (join, etc).