Solucionado (ver solução)
Solucionado
(ver solução)
6
respostas

Ajuda no entendimento das relações

Fiquei bem perdido do capítulo 2 em diante, entendi a relação das tables através do campo de ligação relacionado nomeado %_id em ambas, mas a progressão da explicação dos capítulos foi rápida demais, em minha opinião seria interessante alguma forma de visualizar graficamente essas relações pra entender o porquê de uma sequência tão grande de joins quando desejamos consultar apenas poucos campos, exemplo:

select a.nome, c.nome, avg(n.nota) from 
nota n
join resposta r on r.id = n.resposta_id
join exercicio e on e.id = r.exercicio_id
join secao s on s.id = e.secao_id
join curso c on c.id = s.curso_id
join aluno a on a.id = r.aluno_id
group by c.nome, a.nome
having avg(n.nota) < 5

Outra dúvida é a questão da nomenclatura, qual o motivo mesmo (talvez eu tenha deixado passar na explicação) de darmos a letra antes do campo a ser utilizado (ex o 'r' em 'resposta r on r.id') , esse alias é pra facilitar em querys muito grandes onde o mesmo deve ser chamado varias vezes e é bom criar o costume de escrever o código sql assim?

6 respostas

Olá!

O motivo de usarmos 'resposta r on r.id' é para uma melhor estrutura da query. Poderia ser resposta.id, assim como aluno.id, estaria correto. É bom ter o costume de escrever as querys criando apelidos para as tabelas pois geralmente o uso de banco de dados de empresa são muito grandes e isso facilita na hora dos JOINS, justamente como você disse, ''o mesmo deve ser chamado varias vezes''.

Entendo, então é bom criar o costume. A partir do momento que foi declarado que Resposta vai ser apelidado de R posso sempre chamar a coluna resposta por r.%?

Sim sim. Pode!

Alguma sugestão pro melhor entendimento das joins e a construção das tables, por que preciso seguir uma sequencia tão grande de joins pra consultar poucos campos etc? Alguma outra fonte, aula, livro pra suplementar a aula?

solução!

Nos exemplos do curso, o "alias" (o apelido atribuido a tabela) é necessário para evitar conflito de campos, por exemplo, o campo "id" existe em várias tabelas, se você quiser usar o campo "id" nos resultados, precisa especificar a tabela.

Isso não seria necessário se os nomes de campos fossem únicos. Isso pode ser conseguido colocando um prefixo antes do nome do campo. Por exemplo, ao inves da tabela "alunos" ter os campos "nome" e "id", os campos poderiam ter os nomes de "aln_nome" e "aln_id".

Essa questão de ter muitos joins para retornar poucos dados se deve a modelagem de dados. Se você procurar no Google pelo termo "normalização de banco de dados" vai encontrar vários artigos que explicam como criar as tabelas do seu banco de dados. Compartilho um destes links:

http://www.blogdati.com.br/index.php/2010/03/normalizacao-em-banco-de-dados/

Para reforçar a utilidade dos joins, você pode consultar este link:

http://blog.thiagobelem.net/relacionamento-de-tabelas-no-mysql

Marcado para leitura Daniel Bins, agradeço!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software