Proper way to model user groups

Question

So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.

Example:

// Users

Users [id, name, email, age, etc]

// User Groups

Player [id, years playing, etc]

Ref [id, certified, etc]

Manufacturer Rep [id, years employed, etc]

So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?

I just want to be sure that this is the best way to organize it before I build it.

Edit: A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.

A ref would have info regarding the certifications they have and the events they've reffed.

Manufacturer reps would have info regarding their position within the company they rep.

A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.

Just as an example.

Edit 2:

**Player Table
    id
    user id
    started date
    stopped date
    rank
**Ref Table
    id
    user id
    started date
    stopped date
    is certified
    certified by
    verified

**Photographer / Videographer / News Reporter Table
    id
    user id
    started date
    stopped date
    worked under name
    website / channel link
    about
    verified

**Tournament / Big Game Rep Table
    id
    user id
    started date
    stopped date
    position
    tourney id
    verified

**Store / Field / Manufacturer Rep Table
    id
    user id
    started date
    stopped date
    position
    store / field / man. id
    verified

This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.

Answer 1

Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.

It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.

In a relational Database I would do it using the design you described.

Answer 2

The design of your tables greatly depends on the requirements of your software.

E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.

Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.

But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.

The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects. As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.