-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Definir o schema do banco de dados #4
Comments
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 request faltou uma ligação 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? mas não vejo problema em deixar na tabela person, quando o login é feito via rede social, é armazenado algo no banco? |
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:
|
Boa Ideia! só vou adicionar os campos de senha e status na tabela person. status será para controlar os usuários inativos, por exemplo.
front end, back end, mobile, full stack |
Mas o que seria o area entao? |
Pelo que estou vendo, é a mesma coisa! rs da uma olhada no documento |
Eu acho que área seria front end, back end, mobile, full stack. |
@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 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? |
@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 ! |
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. |
@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? |
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.
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: |
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. |
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>
.
|
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. 😄 |
Para continuar basta escrever os modelos dentro do diretório hades/models? Cada classe é um arquivo js ? |
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. |
concordo com o @angeliski, dividir e conquistar! ⚔️ |
Vamo iniciar pelos models e migrations então, para mim parece ótimo. |
@david81brs o @hdamaich pode explicar melhor, mas eu acredito que é isso mesmo. |
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 |
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. |
Acho que podemos criar um repositório com os docs dentro do próprio projeto por enquanto. |
Boa, eu n sei qual é o último scheema que batemos o martelo. Poderíamos até separar as tabelas e colocar elas nas respectivas issues. |
@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. |
Opa @lflimeira Eu vou ver se amanhã consigo criar as issues e já faço meio que o link do schema também |
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 😆 |
Acho q a gente tinha ficado de fazer um dicionário de dados. Se consegue ver isso pra gente @cristianopacheco ? |
Pessoal, vamos retomar isso? |
@lflimeira vamos! |
super topo @cristianopacheco =) |
Show de bola! Da pra gravar e depois gerar um doc no repositório de documentos, pra ficar documentado pra quem entrar depois |
Legal, tenho disponibilidade na semana a partir das 20hrs e nos finais de semana qualquer horário. Só marcar. |
Definir qual banco de dados iremos utilizar (Mysql, Postgres, etc..)
Definir as tabelas e relacionamentos.
The text was updated successfully, but these errors were encountered: