Definir o schema do banco de dados

[cristiano-pacheco]

Definir qual banco de dados iremos utilizar (Mysql, Postgres, etc..)

Definir as tabelas e relacionamentos.

[cristiano-pacheco]

Segue a modelagem que eu montei.

O que vocês acham?

[hdamaich]

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?

[cristiano-pacheco]

@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 (training-center/R2D2#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:

[hdamaich]

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?

[cristiano-pacheco]

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

[hdamaich]

front end, back end, mobile, full stack

Mas o que seria o area entao?

[cristiano-pacheco]

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

[juniorodilton]

Eu acho que área seria front end, back end, mobile, full stack.
Especialização seria Ruby, Python, Swift, Android, etc...

[hdamaich]

@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?

[juniorodilton]

Verdade @hdamaich, deixei passar a skill. Acho que vale essa correção que você colocou!

[lflimeira]

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.

[hdamaich]

@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.

[lflimeira]

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 ?

[angeliski]

@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.

[hdamaich]

@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)...

[angeliski]

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

[cristiano-pacheco]

@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.

[angeliski]

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.

[hdamaich]

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?

[cristiano-pacheco]

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?

[hdamaich]

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?

[lflimeira]

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.

[angeliski]

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.

[cristiano-pacheco]

@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?

[lflimeira]

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.

[lflimeira]

Quanto a "dependencia" do docker? Pq vc acha ruim @angeliski?

[angeliski]

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.

[hdamaich]

@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?

[lflimeira]

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.

[cristiano-pacheco]

@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?

[angeliski]

Entendi. É mais uma decisão de design, eu usaria uma tabela intermediária para gerenciar os requests. Mas acho que uma flag pode ser mais simples mesmo. :)

[lflimeira]

@angeliski n sei se entendi....

[lflimeira]

Sim a flag resolve rápido isso. Só que ela só iria ser default false se for cadastro de mentor.

[hdamaich]

Bom eu acho que conceitualmente está errado a abordagem da flag, person tanto faz se é mentor ou não.
Minha ideia ta mais nos coformes do @angeliski:

• Criar uma tabela request_mentor
• Quando mentor fizer request o person_id da pessoa vai ser adicionado nessa tabela
• Quando um admin aceitar o request esse id é removido da tabela e é adicionado na tabela de mentors

Para saber se é mentor ou não é so relacionar com a tabela de mentors.

[angeliski]

Só uma coisa, eu estou tentando montas o schema da training-center/R2D2#40, só que o modelo não é auto explicativo. Por exemplo, qual é o propósito da tabela levels? E profiles? A pergunta é mais pra levantar a ideia de um dicionário de dados simplificado

[cristiano-pacheco]

@angeliski respondendo a sua dúvida, em relação a profiles, eu acredito que hoje só teria um profile que é admin, mas acho que no futuro pode ser adicionado outros tipos de profiles como moderador, por exemplo.

levels:
completamente iniciante
iniciante com conhecimento básico
intermediário
já atuante

[angeliski]

Obrigado @cristianopacheco Isso me ajuda. Mas você acha válido a ideia de criar um dicionario de dados?

[hdamaich]

@angeliski acho super valida a ideia, pode ajudar bastante a contribuição de novos membros.
@cristianopacheco o que achas de criar PR com um .md descrevendo os dados de cada tabela?

[cristiano-pacheco]

Legal! Boa ideia @hdmaich, deixe comigo. Em 26 de out de 2017 11:08 PM, "hdamaich" <[email protected]> escreveu: @angeliski <https://github.com/angeliski> acho super valida a ideia, pode ajudar bastante a contribuição de novos membros. @cristianopacheco <https://github.com/cristianopacheco> o que achas de criar PR com um .md descrevendo os dados de cada tabela? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2XBW2ODonTuF7s849aYoOeisHQFFRvks5swS0kgaJpZM4P_yPG> .

[lflimeira]

Pessoal, curti a estrutura, por mim podemos continuar com ela 😄

O @hdamaich já disponibilizou a imagem docker, ou seja já podemos começar a criar as migrations. 😄

[david81brs]

Para continuar basta escrever os modelos dentro do diretório hades/models? Cada classe é um arquivo js ?
person.js
profiles.js
areas.js
(...)?

[angeliski]

Eu acho que essa issue era mais pra definir a estrutura. Acho que poderia ser aberta uma issue pra cada model, assim a galera pode ir ajudando e ir vendo o avanço, o que falta e tal.
O que vocês acham @lflimeira e @hdamaich ?

[bernardodiasc]

concordo com o @angeliski, dividir e conquistar! ⚔️

[hdamaich]

Vamo iniciar pelos models e migrations então, para mim parece ótimo.

[lflimeira]

@david81brs o @hdamaich pode explicar melhor, mas eu acredito que é isso mesmo.

[lflimeira]

Então a estrutura está definida? Se já estiver e n tiver dúvidas, aí podemos criar issues das migrations para atacar os problemas e fechamos essa. Faz sentido?

@angeliski @hdamaich @cristianopacheco @david81brs

[lflimeira]

Pessoal @angeliski @hdamaich @cristianopacheco @david81brs, onde podemos deixar a estrutura do BD para facilitar o acesso? Estou pegando aqui para fazer e não lembro como fechou esse assunto.

[angeliski]

Acho que podemos criar um repositório com os docs dentro do próprio projeto por enquanto.

[lflimeira]

Boa, eu n sei qual é o último scheema que batemos o martelo. Poderíamos até separar as tabelas e colocar elas nas respectivas issues.

[cristiano-pacheco]

@lflimeira, o schema que ficou definido foi o último que tem a imagem.

acredito que para prosseguir tem que criar os mapeamentos/migrations/seeds, para cada tabela.

[angeliski]

Opa @lflimeira Eu vou ver se amanhã consigo criar as issues e já faço meio que o link do schema também

[lflimeira]

Então @cristianopacheco eu peguei a rota de pessoas para fazer, aí já estou criando as migrations que tem a ver com pessoas, n é melhor dessa forma? Durante o desenvolvimento me surgiu uma dúvida, o que é o status na tabela pessoa e o que é a tabela permissão?

Boa @angeliski 😃 eu criei um Project no hades, então toda issue que for aberta, ela vai aparecer lá no board em to do, aí fica mais fácil de ver quem está fazendo o que 😆

[angeliski]

Acho q a gente tinha ficado de fazer um dicionário de dados. Se consegue ver isso pra gente @cristianopacheco ?

[lflimeira]

Pessoal, vamos retomar isso?

[cristiano-pacheco]

@lflimeira vamos!
O que acham de marcar uma call?
Agente discute a modelagem e os outros assuntos que o pessoal está pedido.

[lflimeira]

super topo @cristianopacheco =)

[angeliski]

Show de bola! Da pra gravar e depois gerar um doc no repositório de documentos, pra ficar documentado pra quem entrar depois

[cristiano-pacheco]

Legal, tenho disponibilidade na semana a partir das 20hrs e nos finais de semana qualquer horário. Só marcar.