3 respostas neste tópico

[verneklavor]

Boa tarde, sobre um trabalho de faculdade, uma dúvida:

Tenho uma tabela chamada tb_vagas_emprego e tenho uma tabela tb_curriculos. Preciso fazer o cruzamento dessas 2 tabelas e colocar em uma terceira tabela os registros que se repetem nessas 2.

Nesse é relacionamento N para N ??

Como faço esse cruzamento no MySQL? Um select dentro do outro?
Como seria?

Obrigado.

[nickosoft]

acho q você esta confundindo as coisas....
relacionamento entre tabelas é qnd existe pelo menos um campo em comum em ambas as tabelas, esse campo é q cria a relacao....

pense nas vagas de emprego
cod 1 vaga pra tecnico
cod 2 vaga pra programador
no curriculum a pessoa q se candidata vai colocar o codigo da vaga q ele se interessa....
curriculuns
codvaga 1 dados extras....
codvaga 1 outros dados....
codvaga 1 mais dados....
codvaga 2 dados....

agora so nao entendi pq criar uma terceira tabela e colocar o cruzamento das informacoes....
SGBD é muito flexivel, e as querys sao retornadas em memória, um simples inner join ja te retorna essa terceira tabela virtual com os dados....
tipo
select * from curriculuns c inner join vagas v on v.codigo=c.codvaga

[verneklavor]

Perfeito, entendi perfeitamente.

Mas você não acha que fica mais "pesado" para o banco ele toda vez fazer o processo de comparar as 2 tabelas e gerar o resultado em memória, ou seria mais otimizado ele só dar o select na 3º tabela(o resultado do processo de comaração)?

Ou as duas coisas tem o mesmo peso?


Obrigado.

[nickosoft]

usual é nao ter informacoes repetidas em BD, pra isso se faz o relacionamento, memória hj em dia nao é problema, entao o SGBD trabalha legal criando essas tabelas virtuais nas querys.....
agora pra ter a terceira tabela você tem informacoes A em uma, B na outra, e tera uma terceira tabela com A+B e com muito mais registros, tipo como dei o exemplo vaga1, 500curriculuns, essa tabela C vai repetir 500X o registro da vaga, sendo 1 pra cada curriculum cadastrado....agora imagina se ainda for fazer algum select nessa pequena nova tabela...e as atualizações, você em vez de atualizar 1 tabela você passa a no minimo atualizar 2 tabelas, isso é tempo de processamento perdido, assim como o espaco em disco...

muito comum pra ilustrar esse problema é uma agenda de clientes...
os dados do cliente ficam em uma tabela, em outra tabela temos os telefones, relacionados atraves do ID do cliente, onde podemos ter N telefones para apenas um cliente....
muito mais pratico do q termos repetido N vezes o registro do cliente pra cada telefone, ou entao o campo telefone estar na tabela principal com um tamanho enorme, pois nao temos como prever o qnt de informacoes serao colocadas no campo.....