Open cristiano-pacheco opened 7 years ago
Segue a modelagem que eu montei.
O que vocês acham?
Posso ter entendido mal, mas ficou uns pontos em aberto pra mim:
@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:
Uma duvida:
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
front end, back end, mobile, full stack
Mas o que seria o area entao?
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)
skill deveria ser:
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 _personcontact é 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.
@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.
Quanto a "dependencia" do docker? Pq vc acha ruim @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.
@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?
@hdamaich @cristianopacheco Eu acho o Squelize um bom ORM, mas eu até comentei no slack se alguem já tinha trabalhado com ele usando ES6 sem babel, porque os caras aqui no trabalho tiveram problemas com isso. Não vejo problemas em usar ele, só levanto essa bandeira pra galera ter isso em mente. Vocês já usaram ele nesse cenário ?
Bom estou montando a estrutura com Docker usando Migrations do Sequelize, estou pensando em fazer todo banco por Migration, tanto de Schemas, quanto de Seeds.
Hoje a noite devo fazer o PR para vocês avaliarem.
Vixi eu tenho que dar uma olhada @cristianopacheco mas vamos de sequelize.
Obrigado @hdamaich 😃
Aí se puder, só atualiza o resume mostrando como a galera sobe a imagem e tudo mais, vamos mantendo ele atualizado para que as pessoas possam ajudar.
Galera está muito show o engajamento de todos, parabéns!!! 😆
@angeliski usei sim, mas com o node 8.4, mas eu não fui muito afundo, fiz apenas umas brincadeiras e tals.
@hdamaich legal ein! estou curioso pra ver este ambiente rodando com o Docker, vai ser muito interessante!
@lflimeira vc plantou a semente meu amigo! rs
Vamos plantar mais sementes então pq sabado tem Dojo :smile:
Pessoal esqueci de uma coisa na tabela kkk á parte de admins e a parte q um mentor precisa da aprovação de um admin para começar como um mentor 😁
Pessoal esqueci de uma coisa na tabela kkk á parte de admins e a parte q um mentor precisa da aprovação de um admin para começar como um mentor 😁
A parte de person_permission não soluciona esses dois problemas? Você pensou em algo diferente?
@hdamaich Eu acho que a _personpermission resolve bem a questão do admin, mas acho que fica em falta o esquema de aprovação de mentor. Por exemplo, eu entrei na plataforma e quero ser mentor, como o database registra essa "solicitação" para ser mentor? Depois de aprovado ele pode receber uma permissão de mentor, mas e o caminho intermediário? Pode até ser o caso de conceder uma permissão intermediária pra identificar, mas acho que fica estranho... sei lá.
Pode ser, mas tem que ter um booleana para dizer se está ativo ou não.
@lflimeira Não faz mais sentido remover o registro de _personpermission do que ter uma flag?
Então a ideia seria entro e me cadastro como mentor. Só que n estou liberado para fazer nada... aí quando o admin liberar aí tenho livre acesso de mentor.
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. :)
@angeliski n sei se entendi....
Sim a flag resolve rápido isso. Só que ela só iria ser default false se for cadastro de mentor.
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:
Para saber se é mentor ou não é so relacionar com a tabela de mentors.
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
@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
Obrigado @cristianopacheco Isso me ajuda. Mas você acha válido a ideia de criar um dicionario de dados?
@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?
Legal! Boa ideia @hdmaich, deixe comigo.
Em 26 de out de 2017 11:08 PM, "hdamaich" notifications@github.com 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 https://github.com/training-center/hades/issues/4#issuecomment-339843953, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2XBW2ODonTuF7s849aYoOeisHQFFRvks5swS0kgaJpZM4P_yPG .
Definir qual banco de dados iremos utilizar (Mysql, Postgres, etc..)
Definir as tabelas e relacionamentos.