Relacionar X Não Relacionar Tabelas - Qual a sua opnião?
Saudações,
Me desculpem se a questão for antiga, e caso for gostaria por gentileza, que me indicassem uma palavra chave, para tal solução, pois estou pesquisando durante a manha inteira e ainda não tive nenhuma resposta conclusiva.
Assunto: O relacionamento entre tabelas ( Chave-primaria x Chave estrangeira), altera a velocidade do processamento do banco ou apenas prove regras, com intuito de minimizar erros humanos.
Por exemplo:
TBCliente.IDCliente -> (1:1)TbEnderecos.IDCliente
e
TBCliente.IDCliente -> (1:N)TbTelefones.IDCliente
O relacionamento me traria vantagens em caso de exclusão involuntária, mas teria alguma vantagem no caso de consultas envolvendo uma clausula JOIN com 2 ou mais tabelas e vários registros? Aparentemente me parece ser mais vantajoso, no momento em que estou normalizando ainda meu banco de dados, e por isso desenvolvendo varias alterações, utilizar o mínimo possível de relacionamentos. Não encontrei nenhuma matéria na net explicando as vantagens a nível de compilação para o relacionamento, fora à garantia de restrição preventiva de erros.
Alguém teria uma opinião melhor fundamentada para auxiliar este curioso leigo, agradeço links, já li bastante sobre o assunto na wikipedia e umas duas apostilas, porem parece que todo mundo aceita o relacionamento como algo obviamente natural e inquestionável.
Grande abraço,
8) Vagner Wolf
Me desculpem se a questão for antiga, e caso for gostaria por gentileza, que me indicassem uma palavra chave, para tal solução, pois estou pesquisando durante a manha inteira e ainda não tive nenhuma resposta conclusiva.
Assunto: O relacionamento entre tabelas ( Chave-primaria x Chave estrangeira), altera a velocidade do processamento do banco ou apenas prove regras, com intuito de minimizar erros humanos.
Por exemplo:
TBCliente.IDCliente -> (1:1)TbEnderecos.IDCliente
e
TBCliente.IDCliente -> (1:N)TbTelefones.IDCliente
O relacionamento me traria vantagens em caso de exclusão involuntária, mas teria alguma vantagem no caso de consultas envolvendo uma clausula JOIN com 2 ou mais tabelas e vários registros? Aparentemente me parece ser mais vantajoso, no momento em que estou normalizando ainda meu banco de dados, e por isso desenvolvendo varias alterações, utilizar o mínimo possível de relacionamentos. Não encontrei nenhuma matéria na net explicando as vantagens a nível de compilação para o relacionamento, fora à garantia de restrição preventiva de erros.
Alguém teria uma opinião melhor fundamentada para auxiliar este curioso leigo, agradeço links, já li bastante sobre o assunto na wikipedia e umas duas apostilas, porem parece que todo mundo aceita o relacionamento como algo obviamente natural e inquestionável.
Grande abraço,
8) Vagner Wolf
Vagner Wolf
Curtidas 0
Respostas
Emerson Nascimento
17/06/2008
ao relacionar fisicamente as tabelas você perde um pouco em performance, pois qualquer manutenção num registro de uma tabela terá de passar pela avaliação dos relacionamentos (integridade referencial, cascades e etc).
e mesmo a manutenção dos índices criados para tais relacionamentos/chaves primárias gera uma pequena perda de performance.
mas essa perda de performance é compensada pela maior velocidade - muito maior - nas consultas (índices) e pela integridade dos dados, que é muuuito importante para gerar qualquer tipo de informação..
eu recomendo o uso de relacionamentos.
e mesmo a manutenção dos índices criados para tais relacionamentos/chaves primárias gera uma pequena perda de performance.
mas essa perda de performance é compensada pela maior velocidade - muito maior - nas consultas (índices) e pela integridade dos dados, que é muuuito importante para gerar qualquer tipo de informação..
eu recomendo o uso de relacionamentos.
GOSTEI 0
Pestana_
17/06/2008
e acima de tudo precisamos garantir o que é mais valioso os dados! eu prefiro deixar o maxímo possive o banco normalizado para garantir a integridade dos dados! a aplicação seria mais uma consequência de como você tratou o seu banco, pelo menos eu penso assim!
flw.
flw.
GOSTEI 0