Descrição de entidades

[cherryramatisdev]

Usuário

• dados de usuários (discutir quais infos queremos como username, nickname, email, discord_id, etc)
• senha

Perfil de usuario

• imagem de perfil
• se é um mentor ou não

Projetos

• nome do projeto
• descrição do projeto
• link para o projeto (pode ser GitHub ou website próprio)
• stacks usadas (aqui talvez caiba outro relacionamento)
• membros do projeto (aqui talvez caiba outro relacionamento)

Ferramentas/Linguagens

• nome

[cherryramatisdev]

Proposta: https://dbdiagram.io/d/643ca8016b31947051b0a622

Comentarios:

1. Relação entre tabela de projetos e tabela de stack precisa ser 1:N
2. Relação entre tabela de usuário e tabela de stack precisa ser 1:N
3. Precisa haver uma relação entre usuário e projeto, 1:N
4. Campos como discord_email, discord_name nao deveriam existir, pois ja temos campos de email e nome
5. Campo discord_avatar deveria representar o que exatamente? o base64 da imagem ou uma url para CDN?
   • Sobre os outros campos urlImageProfile, urlGithubUsuario, urlLinkedinUsuario não deveriam existir pois teremos apenas uma foto de perfil para o usuário.
6. Campo discord_discriminador deveria representar o que exatamente?
7. Campo statusUser deveria representar o que exatamente? se for para soft delete, podemos usar um booleano ao invés de um varchar.
8. Tabela cargo pode se chamar position (revisar outras tabelas para ser em ingles tambem)
9. Precisamos de uma nova tabela chamada role que vai ser 1:N com a tabela de usuário.

Exemplo: 1 usuário pode ter apenas um cargo, sendo eles "moderador" ou "mentor" ou "membro"
Multiplos usuários podem ter o mesmo cargo.

10. Nome, email e senha devem ser hasheados.

Nomenclatura

Precisamos decidir se vamos usar camelCase ou snake_case nas tabelas do banco de dados e manter adequado, o importante é ter consistência com um padrão único.

Detalhe de implementação

No primeiro momento que o usuário cadastrar no nosso sistema, ele pode escolher tanto por discord ou por email padrão, e em ambos os casos vamos preencher o máximo de informação possível (email, nome, etc...), dessa forma temos uma autenticação o mais homogênea possível entre múltiplos providers.