I am fairly new in the firebase/backend world. I have started learning recently. So I have decided to make a sample project to learn. The project is more like job profile such as LinkedIn/Smartr. I am struggling to make a decision how I should structure my database.

I am using Angular 13 in frontend and Firebase(@angular/fire) as backend.

So the project I am trying to build is a very simple. It will have some basic info of a user such as firstName, lastName, age, title, location. These are the basic information which will be necessary to complete a profile.

So in Firestore I have made a collection called Users where for each user have a document id that is generated with the following information.

{
  age: 23,
  email: "[email protected]",
  firstName: "Demo",
  lastName: "User",
  title: "Engineer"
  location: "USA"
  uid: "232dsf23"
}

The system will also have a authentication system. Using the already defined firebase authentication system.

So the uid I am keeping is the id I am getting in response after a user is signed up. I am using that as the Users Document Id.

So far I have done this. So the next thing I want to add in my demo project is the a Work Experience section.

The functionality will work exactly like we see in LinkedIn/Smartr. A user can only add/edit only one work experience at a time using a modal/dialog.

So my queries are:

1. Should I include workExperience a new object property in each document of users collection. If I keep a new property called workExperience in the documents of users collection then I am going to need an id with each experience if i am not wrong because a user can edit/update only one experience at a time. So since firebase doesn't support auto incremental id (as far as I read) then how should I approach it?

2. If I make a separate collection called work-experience where adding a new experience will create a new document in that collection for every user then how would I connect that which experience is related to which user? And how should I query to get the expected data.

Which procedure should I follow? If you any have other suggestion how I should approach it please suggest.

CodePudding user response：

The answer is highly depending on how you will display this data in your front-end.

If you plan to show on the same screen the basic user info and the work experience then the best is to add the work experience to the user's Firestore document: you execute only one query for this screen.

On the other hand, if you plan to first show a screen with the basic user info which has a link/button to open another screen showing the work experience then it make sense to store the work experience data in an other document. You query this data only when the end user decides to display it.

For that you can have a "separate collection called work-experience" as you mentioned, and for each user you use the userID as the ID of the work experience Firestore Document (you can very well reuse the same Document ID across different collections). This way it is very easy to query the work experience Document of a specific user: just swap the collection name in your query.

- users (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...
- work-experiences (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...

If you plan to have some extra sections similar to the work experience section, e.g. education or hobbies, you can use the same approach

- users (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...
- work-experiences (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...
- educations (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...
- hobbies (collection)
  - userId1 (doc)
  - userId2 (doc)
  ...

---

But another interesting approach is to have, for each user, a sub-collection named for example details-sections, where you store those documents with a fixed ID:

- users (collection)
  - userId1 (doc)
    - details-sections (sub-collection)
       - work-experience (doc)
       - education (doc)
       - hobbies (doc)
  - userId2 (doc)
    - details-sections (sub-collection)
       - work-experience (doc)
       - education (doc)
       - hobbies (doc)

The main advantage of this data model is that it is easy to navigate into a user's data from the Firebase console. From a query performance or cost perspective, it is exactly similar to the previous data model. Security rules are a little bit different between the two models but nothing that would really influence the choice between those two models.