📝 Suggestion For Project Relationships (ERD)

[taljacob2]

This is the ERD @DeanBiton posted on our slack:

---

I converted this image to mermaid markdown, so now we can all edit the graph together.

You are welcome to make changes to this graph. (You can view the simple guide about how to edit mermaid ERD graphs here)
⬆️ ⬆️ ⬆️ Press on the graph above to make changes on it. ⬆️ ⬆️ ⬆️

NOTE:
You can save backup versions while you edit the graph by pressing the green "save" button, and "restore" when you want to.

By the way, once you have pressed on the graph, you can view it on full screen, by pressing the "View" button in the top right corner:

---

Edits Made Since @DeanBiton's Post On Our Slack, That Require Discussions

• I added a "CREDENTIALS" table to be referenced from "USER" (This is a good feature if we want to use "Google / Facebook Signup" in the future). Please comment here if this is something we should go for or not.

• I split the "JOB-TYPE" and "YEARS-OF-EXPERIENCE" to their own tables, because they both represent enums with limited option sets.

  • "JOB-TYPE" enum is (for example):
    • IT Support
    • Software Developer
    • Engineer
    • Salesman
    • Police Officer
    • ...
  • "YEARS-OF-EXPERIENCE" enum is (for example):
    • No experience
    • 0-2 years
    • 2-5 years
    • 5-10 years
    • More than 10 years

• We divided the features between us, and I am assigned to work on the "Chat". I need assistance from @Yarboa @kasemAlem @rrasouli about the relationships for the "CHAT" (Can you please comment here your thoughts about the "CHAT" table?). I tend to think this is a "many to many" relationship, so I edited the ERD version @DeanBiton has posted on our slack to what I think we should do, but I am not sure about this. In the new edited version of the graph, it is possible that a chat may bundle multiple users together for a conversation (to support unlimited number of users).

[rrasouli]

Hi, Can you elaborate on what is the parent comment FK is?
THX

[paOmer]

Hi, Can you elaborate on what is the parent comment FK is?
THX

Hi,
The parent will be NULL if this is a direct comment of the post itself, and will be asign with another comment ID as a FK in a case where it is a reply to a comment.

This model allows for "reply on top of reply" or a comment to a comment, and was shown in the previous Beyond session by Sim.

[taljacob2]

Hi, I just found out that "PREFERENCES"'s "location" should also be an enum:
For example:

• South
• West Bank
• Jerusalem
• Central
• North
• Ha'Shfela
• Sharon

So I made an edit to the graph here:

[paOmer]

I have deleted the relationship between personal profile and preferences as only the job-offer should have its different preferences and a job-seeker will filter out different job-offers according to it's preferences.

[amittcohen]

I think that the user should only contain the relevant attributes for logging in (such as credentialsId),
so the birth date should move to the personal profile.
WDYT?

[amittcohen]

Also, since we have the user model in Django (https://docs.djangoproject.com/en/4.0/ref/contrib/auth/),
Do we need the credentials table seperately in the diagram?

[paOmer]

I think that the user should only contain the relevant attributes for logging in (such as credentialsId), so the birth date should move to the personal profile. WDYT?

@amittcohen I think you're right and the birth date should move to the personal profile.
@ShirleyFichman as the personal profile maintainer what do you think?

Also, since we have the user model in Django (https://docs.djangoproject.com/en/4.0/ref/contrib/auth/),
Do we need the credentials table seperately in the diagram?

I'm not sure why we even decided to separate it in the first place.

[taljacob2]

I think that the user should only contain the relevant attributes for logging in (such as credentialsId),
so the birth date should move to the personal profile.
WDYT?

Good idea.

Also, since we have the user model in Django (https://docs.djangoproject.com/en/4.0/ref/contrib/auth/),
Do we need the credentials table seperately in the diagram?

I added the credentials table as an offer for us to discuss. I think it is helpful if we choose to use credentials from Google / Facebook signups.
But if we go for the user model provided in Django, then we can remove the credentials table.

[paOmer]

Updated post and comment, also added likes:

[ShirleyFichman]

I think that the user should only contain the relevant attributes for logging in (such as credentialsId), so the birth date should move to the personal profile. WDYT?

@amittcohen I think you're right and the birth date should move to the personal profile. @ShirleyFichman as the personal profile maintainer what do you think?

Also, since we have the user model in Django (https://docs.djangoproject.com/en/4.0/ref/contrib/auth/),
Do we need the credentials table seperately in the diagram?

I'm not sure why we even decided to separate it in the first place.

@paOmer @amittcohen @taljacob2
All right I agree to add birthday as part of the personal profile model, so does that mean that we only use the user model from Django?

Also, wanted to make sure that "preferencesID" is not part of the personal profile model since it's related to posts and jobs only.

[ShirleyFichman]

Deleted birthday from the user model and added it to personal profile- I've seen that we wrote string on the data type but it's preferred to have it as date, right?
Also, deleted "preferencesID".

[taljacob2]

Deleted birthday from the user model and added it to personal profile- I've seen that we wrote string on the data type but it's preferred to have it as date, right? Also, deleted "preferencesID".

I removed the CREDENTIALS table now.

[taljacob2]

@ShirleyFichman

• All right I agree to add birthday as part of the personal profile model, so does that mean that we only use the user model from Django?

  Yes. We will use the user model from Django.

• Deleted birthday from the user model and added it to personal profile- I've seen that we wrote string on the data type but it's preferred to have it as date, right?

  I'm not entirely sure what type the birthDate should have. Need your help here.

[taljacob2]

Edited "MESSAGE"'s properties to be similar to "COMMENT" and "POST".

[taljacob2]

@ShirleyFichman

• Deleted birthday from the user model and added it to personal profile- I've seen that we wrote string on the data type but it's preferred to have it as date, right?

  I'm not entirely sure what type the birthDate should have. Need your help here.

Found it! It should be DateField. (So this is the same as DateTimeField but without the "time").
As shown here.

Updated the ERD:

[ShirleyFichman]

@ShirleyFichman

• Deleted birthday from the user model and added it to personal profile- I've seen that we wrote string on the data type but it's preferred to have it as date, right?

  I'm not entirely sure what type the birthDate should have. Need your help here.

Found it! It should be DateField. (So this is the same as DateTimeField but without the "time"). As shown here.

Updated the ERD:

@taljacob2 Thank you! I will also change it on the models.py file.

[DeanBiton]

Some thoughts about the job_board's data models:

1. Location table:
   The location will be a name of a city, which is more specific.
   Furthermore, for each city, I will add coordinates like North, East so when a job
   was not found for the city requested I can find the next nearby job.
   If we want, we can still have regions in the table in case the job is not on the cities list.

2. Job_Type table:
   Do we want to limit ourselves to 1 job-type per job?
   Because jobs can have multiple "types",
   like a full-stack developer which is also a back-end developer.
   Haven't found a solution for this, maybe a hashtag system.

[taljacob2]

@DeanBiton Overall great ideas!

1. About the Location table:

   I am not entirely sure I understand. Can you please explain this again?
   You mean that we would have another table of "CITY", where each "LOCATION" has multiple cities? With 1:N relationship between them?

   erDiagram
   LOCATION ||--|{ CITY : has
   

   Loading

   That sounds nice but I think this is pretty much advanced to create as a MVP. Though, if you see yourself able to do so this can be great!
   So you mean, the client "user" / "employers", will filter their job "location" preferences for either a LOCATION or a specific CITY?

2. About the "JOB-TYPE" table:

   The "hashtag system" sounds awesome!

   • If you find yourself able to create it you are welcome to go for it.
   • If not, then our simple solution for now is good enough as a MVP. We can always continue working on the "hashtag system" afterwards as a "TODO" goal.

[DeanBiton]

@taljacob2

1. The Location table after changes:

2. I think leaving the "hashtag system" in a "DOTO" is best for now.

[taljacob2]

@DeanBiton

1. Ohh I see now. Nice!
   So how will the client filter for locations?
   For example, he will state in the form that he wants to search for "Rehovot" in a radius of a number of kilometers around "Rehovot"?
   If you can do so this can be cool!

2. Alright. Sounds good to me.
   You can create a new issue out of your comment, so we would see all of this thread when we will work on the issue.
   

[DeanBiton]

@taljacob2

1. My thought was that someone will search for "Tel aviv" and if there aren't any jobs in "Tel aviv",
   I will calculate the next nearby city and bring up the results from there like "Holon".

   On the one hand giving the user a radius of a number of kilometers around a city sound great and interesting,
   but on the other hand i don't want the search to be excessively complicated.

2. Done 🏇 Adding multiple "job-type" to a single job post #48

[taljacob2]

@DeanBiton

Alright it sounds promising! You can go for it! If you are having issues with implementing we are here to assist you.

[DeanBiton]

Updated the Location table:

[taljacob2]

UPDATE

• Updated USER-CHAT module:

  • Deleted USER-CHAT, from being an explicitly "Many To Many" table, to be more concise thanks to the ability to do so with Django's ORM's models.ManyToManyField and to @paOmer's example in post.py.
  • In MESSAGE:
    Updated author_id to be a FK, and set a visual relation line of "One To Many" between USER and MESSAGE.

• In COMMENT:
  Set a visual relation line of "One To Many" between USER and COMMENT.

• In LIKES:
  Set a visual relation line of "One To Many" between USER and LIKES.

• Global Update:
  Edited the comments on the relation lines for consistency:

  • When there is a relation of ||--o{, the comment will have an additional prefix of "may" in the beginning.
  • When there is a relation of ||--|{, the comment will not have an additional prefix of "may" in the beginning.

  

[paOmer]

Looking good!
We could use it on the demo

[amittcohen]