hades
hades copied to clipboard
training-center
Definir o schema do banco de dados
Definir qual banco de dados iremos utilizar (Mysql, Postgres, etc..)
Definir as tabelas e relacionamentos.
Posso ter entendido mal, mas ficou uns pontos em aberto pra mim:
- mentoring_skills faltou a ligação com mentoring
- request faltou uma ligacao com as skills e area que estão sendo requisitadas
- o que seria o level no request, parece que deveria ter um level por skill e não por request, por que o level da pessoa já esta no person
- user não deveria ser um person tb?
@hdamaich obrigado pela revisão.
mentoring_skills faltou a ligação com mentoring resolvido, eu não tinha criado a chave primaria para a tabela mentoring.
request faltou uma ligação com as skills e area que estão sendo requisitadas Bem observado, fiz a correção.
o que seria o level no request, parece que deveria ter um level por skill e não por request, por que o level da pessoa já esta no person coloquei este campo baseado na issue que o @bernardodiasc abriu (https://github.com/training-center/R2D2/issues/40) mas olhando novamente eu acredito que também não há necessidade.
user não deveria ser um person tb? isso eu estou com dúvida, nos requisitos está descrito que o email do usuário pode ser diferente do cadastrado na plataforma via login social,
mas não vejo problema em deixar na tabela person, quando o login é feito via rede social, é armazenado algo no banco?
segue o DER com as alterações:
user não deveria ser um person tb? isso eu estou com dúvida, nos requisitos está descrito que o email do usuário pode ser diferente do cadastrado na plataforma via login social,
Certo, acho que sim, mas no person podemos deixar o email como email de login, e nos contatos podemos ter um email de contato.
Outros pontos de revisão:
- person_contacts ta meio estranho parece, contacts seria o tipo de contato correto? Onde exatamente vai o contato em si? Para mim contacts deveria ter os tipos de contato (email, github, linkedin...) e person_contacts ter mais um campo para o contato em si.
Uma duvida:
- O que é especialização de um mentor?
Certo, acho que sim, mas no person podemos deixar o email como email de login, e nos contatos podemos ter um email de contato.
Boa Ideia! só vou adicionar os campos de senha e status na tabela person. status será para controlar os usuários inativos, por exemplo.
O que é especialização de um mentor?
front end, back end, mobile, full stack
Pelo que estou vendo, é a mesma coisa! rs não sei o que o @woliveiras pensou quando escreveu os requisitos, talvez esteja duplicado mesmo.
da uma olhada no documento https://github.com/training-center/hades/blob/master/requisitos_plataforma.md
Eu acho que área seria front end, back end, mobile, full stack. Especialização seria Ruby, Python, Swift, Android, etc...
@cristianopacheco @odilton
Bom para mim area deveria ser (vou fazer um PR para corrigir isso na definição)
- front end, back end, mobile, full stack
skill deveria ser:
- Ruby, Python, Swift, Android, etc...
E especialidade está sobrando, tem mais alguma coisa que perdi?
Verdade @hdamaich, deixei passar a skill. Acho que vale essa correção que você colocou!
Eaee Pessoal, então o BD vai ser Postgres, alguém tem outra opinião quanto a isso?
Alguns pontos, quanto as infos de login, onde elas estariam? Eu nunca mexi com login social, mas n deveriamos guardar algo?
Outra questão, será que não podemos desnormalizar um pouco isso? Ex: A parte de person_contact apenas uma forma de contato que nós utilizamos, que é o email. Acho que isso serve para outras coisas tbm. Obs: Podemos ter um campos das redes sociais, mas não usamos ela como contato.
@bernardodiasc junte-se a nós.
Galera, fora isso o que faltamos para fechar isso? A ideia é fazer um Dojo no sábado, e seria legal já ter a base de dados.
@lflimeira A relação com person_contact é 1 pra N pelo que entendi, logo uma pessoa pode ter vários contatos. Cada tipo de contato vai pra contatcs pelo que entendi, como github, facebook, twitter etc...
Sobre o tipo de login podemos abrir uma issue só pra isso, a estrutura que temos aqui acho que não se adapta mesmo.
Então, mas não seria melhor deixar isso fixo? Redes sociais não é uma coisa que muda com frequência saca? Mas assim tbm funciona, então n vejo como impeditivo rsrsrs
Pois é, precisamos alinhar isso do login social o quanto antes, para dar continuidade com o projeto.
Minha sugestão é que assim que fechar a modelagem do BD poderia criar uma imagem docker do BD, o que acha @hdamaich ?
@cristianopacheco Eu não entendi bem a função da contacts. Eu tenho campo name ali, mas onde vai o valor em si? Por exemplo, eu tenho uma person que tem facebook e twitter. Onde vão esses dados? Se eles vão na tabela contacts, como eu consigo diferenciar twitter de facebook? @lflimeira e @hdamaich Normalmente em casos de login social nós guardamos o access_token e o refresh_token (Onde a grande maioria dos cenários são de OAuth2), mas eu nunca tive que trabalhar com multiplos logins sociais de uma vez, talvez uma solução seja gerar um JWT para o usuário... OU delegar isso para um provedor, tal como o auth0.
@lflimeira Isso, amanha pretendo montar uma estrutura com Docker pra nossa aplicação, com banco + aplicação, para todo mundo conseguir usar em sua casa sem se preocupar com instalações.
@lflimeira @angeliski Vamos criar uma issue para discutirmos apenas a estratégia de login, o que acham? Mas adianto que OAuth2 parece ser o que precisamos. #6
@angeliski Sobre o contats, ainda falta algumas modificações nos campos da tabela como comentei mais acima, pelo que entendi funcionará assim.
- contacts será um índice para os possíveis tipo de contatos que podemos ter, EX: github, facebook...
- person_contacts terá os contatos de cada pessoa, linkando para o tipo de contato e para pessoa (ainda falta um campo para armazenar o contato em si, @cristianopacheco)
@lflimeira Acho ruim fixar a quantidade de contatos, pois algum dia pode surgir coisas novas que façam sentido termos o link, tipo perfil em alguma plataforma de RH (coisa do tipo)...
Entendi @hdamaich, nesse caso a tabela contacts seria mais como se fosse o tipo(github, facebook, linkedin), certo? Nesse ponto eu concordo um pouco com o @lflimeira em relação a desnormalização, um enum direto na person_contacts não seria mais eficiente? Nesse caso eu teria mais um join só pra saber que é um Github da vida
@hdamaich @lflimeira @angeliski
Segue a modelagem com as correções.
Sobre a autenticação, podemos deixar desta forma por enquanto e seguir, por que já resolve primeira forma de autenticação mais simples baseado em usuário e senha. Quando for implementado o login via rede social, agente cria os campos/tabelas necessárias para esta funcionalidade.
Sobre os contatos, eu prefiro deixar separado por que fica mais genérico e atende a mais situações e evita deixar campos sem valor na tabela.
Se vocês concordarem com esta modelagem, eu vou gerar o db para o postgres e anexar no projeto.
O próximo passo seria criar uma issue para mapear estas tabelas no ORM (Sequelize).
Como vamos resolver a questão dos dados default, vamos criar migrations ou vai existir um banco já com estes dados no projeto?
ex: de dados default -> areas, skills, contacts, permissions, levels.
Show @cristianopacheco ! Com relação aos dados, aqui na empresa nós usamos uma database manager chamada Bee, é uma solução open que criamos para nos atender. Nele tem o conceito de dbseed, que são esquemas de semente e de dados core, que são tabelas que tem dados "inalteráveis" pela aplicação. Tem o Flyway, mas esse eu usei uma vez só a muuito tempo.
Sobre abordagem dos dados, como vamos usar uma imagem docker, tanto faz a abordagem, ambas vai ser "click to play".
Migration serve pra documentar o DB tambem, mas pelo que eu vi no Sequelize as migrations ficam meio zoadas (impressao que tive). Voces tem experiencia em usar Migration do Sequelize?
Legal @angeliski, vou dar uma olhada no Bee. Flyway já usei com Java é bem bacana mesmo.
@hdamaich, eu penso em usar as migrations mais para os dados, por que se mapear entidades 100% com o Sequelize, ele ja cria os metadados de forma automática.
ou
Posso gerar o banco de dados com a estrutura inicial (Tabelas e dados) colocar o backup no projeto, e rodar um comando com o docker para restaurar o backup ou algo deste tipo.
O que vocês acham?
Nao estou 100% certo disso, mas se vamos manter uma estrutura consolidada, entao mantemos com dados base tambem. Voces veem alguma vantagem em outra abordagem?
Olha eu aqui renovo povo kkkkk então eu sou a favor de migrations, se o do sequelize é zuado, bora usar mongoose. E eu acho que a tabela está show agora.
Eu sou a favor de migrations porque acho que a base tem que ser "reproduzivel" a qualquer momento, acho ruim criar uma dependencia com o Docker, mas isso já é uma opnião, não sei dizer a vantagem e desvatagem da abordagem em si.
@hdamaich @lflimeira @angeliski
vamos criar as migrations então! rs
bom, saímos do zero! definimos a estrutura inicial das tabelas agora é so começar a implementar.
acredito que esta issue esta concluída, certo?
Vamos considerar concluída quando o docker estiver na master pode ser?
Assim que subir o docker eu já mando bala no endpoint de cadastro, e preparo tudo para o nosso Dojo.
Acho que eu me expressei mal @lflimeira . Não é que é ruim ter o Docker, ele é uma ferramenta super top e tem que ser usada mesmo. O que eu acho ruim é que sem o docker, não tem como subir uma base. Você não consegue reproduzir o database fora dele (nesse caso), já que todas as modificações e alterações são imagens novas dele. Claro, isso é mais uma questão de opinião mais que uma definição técnica. Se vc tem um schema inicial e uma migração para as alterações, a qualquer momento você consegue criar o schema e subir as alterações tendo uma base igual a de produção.
@angeliski @lflimeira Vou fazer de uma forma que de para rodar com ou sem docker. Só que quem tiver sem docker vai ter que fazer os passos na mão.
@cristianopacheco @angeliski @lflimeira Vamos usar Sequelize mesmo?
Então com a migration eu acho que já da para subir o ambiente, o que seria bom de forçar o docker é o fato de que todos trampam no mesmo ambiente. Principalmente por ser um código open.
@hdamaich pode mandar bala, então se a migration do mongoose for melhor podemos usar ele. O do sequelize eu realmente n manjo.
@hdamaich Sequelize foi uma ideia, acho interessante agente usar um ORM, mas se vc quiser indicar outro, não vejo problema. Uma outra opção que conheço é o Knex.
@lflimeira, da para usar o mongoose com postgres?