Fórum Normalização de dados #487359

30/07/2014

0

Olá amigos.

Quero saber da experiencia de vocês.
O que é mais vantajoso, seguir as formas de normalização e criar por vezes n tabelas obedecendo essas formas, e futuramente correr o risco de usar joins imensos e pesados para realizar consultas ou reutilizar tabelas para inserir campos que possam ter relação indireta com a chave primária?
Ou no caso de generalização e especialização, quando decidir criar mais que uma tabela?

Agradeço qualquer ajuda.
Valquiria Silva

Valquiria Silva

Responder

Post mais votado

30/07/2014

olá Valquiria, a melhor opção é fazer uma modelagem e seguir as normas para em hipotese alguma vc ter problemas.

Alan Mario

Alan Mario
Responder

Gostei + 2

Mais Posts

31/07/2014

Valquiria Silva

Olá Alan obrigada pela resposta vou revisar minha modelagem.
Responder

Gostei + 0

31/07/2014

Marisiana Battistella

Concordo com o Alan!
Com a estrutura bem elaborada e com os recursos bem utilizados, dificilmente vc terá problemas.
Responder

Gostei + 0

31/07/2014

Alex Lekao

Ola Bom dia!!!

Penso eu que tudo vai depender basicamente do seu projeto e da analise, se a 1FN atende, blz, ou se o ideal eh chegar a Boyce e Cod(acho que eh assim que escreve, nao lembro mais. rsrsr).

Alguns analistas/especialistas no assunto, dizem que se o seu banco chegar na 3FN ja estara de bom tamanho e atendera os requisitos de desempenho e normalizacao.

Lembrando que alguns problemas nos desempenhos de bases bem normalizadas sao minimizados com indices bem criados e views bem elaboradas.

Um ponto importante na montagem dos codigos eh entender bem o algoritimo que o banco trabalha por tras dos scripts utilizados.

Parece loucura, mas estudar e entender bem algebra relacional ajuda a entender bem o funcionamento dos algoritimos do banco.

e levar sempre em conta as diferencas entre um banco e outro e certas estruturas funcionam melhor em um que outro.

Espero ter ajudado.

Abraco.
Responder

Gostei + 0

01/08/2014

Alan Mario

Olá Alan obrigada pela resposta vou revisar minha modelagem.


qualquer probleminha ou duvida, estamos aqui.
Responder

Gostei + 0

02/08/2014

Mariana Carvalho

Parece loucura, mas estudar e entender bem algebra relacional ajuda a entender bem o funcionamento dos algoritimos do banco.


vejo que ultimamente isso está sendo deixado de lado, algebra relacional só se vê em faculdade, não deveria ser somente nesse ambiente.
Responder

Gostei + 0

02/08/2014

Marisiana Battistella

Eu acho q tem "coisas" que não são mais vistas em função dos frameworks que já fazem boa parte do trabalho.
Responder

Gostei + 0

03/08/2014

Mariana Carvalho

Eu acho q tem "coisas" que não são mais vistas em função dos frameworks que já fazem boa parte do trabalho.


infelizmente está assim, mas deveria pelo menos explicar.
Responder

Gostei + 0

03/08/2014

Mariana Carvalho

pessoal, pensando em situação, quando um profissional de banco de dados já pega um banco mal modelado, como fica a normalização quando se quer "consertar"? refaz o banco?
Responder

Gostei + 0

04/08/2014

Alex Lekao

ai depende muito.

o SQL Server tem uma ferramenta que vc consegue dividir as tabelas para vc corrigir normalizacoes.

Um exemplo seria a tabela de clientes com o endereco completo do cliente, depois de um tempo vc pode separar os dados de endereco da tabela e utilizar o campo cep como relacionamento entre a tabela nova e a tabela de clientes.

Nesse exemplo vc teria um unico cadastro de endereco e se tivesse cadastros separados de clientes, fornecedores, fabricantes, funcionarios, vendedores, etc, etc, vc diminuiria consideravelmente o tamanho de espaco etc, etc, e acredito que seria uma boa normalizacao.

mas dependendo do banco valera mais a pena refazer. rsrsr

Abraco.
Responder

Gostei + 0

04/08/2014

Valquiria Silva

Obrigada pelas opiniões.

Estou fazendo um projeto para Firebird.
Uma outra dúvida que me ocorre, é na criação das chaves primárias no caso do relacionamento entre as tabelas, como conseguir boa performance e integridade referencial?
Por exemplo já vi tabelas com até 4 campos formando chaves primárias e todas as tabelas "detalhes ou filhas", carregando estes mesmos campos, no final um custoso e enorme join.

Seria mais eficiente criar apenas um campo "ID" como chave ? Se sim como referenciar os relacionamentos?

Agradeço qualquer ajuda.
Responder

Gostei + 0

04/08/2014

Mariana Carvalho

dependendo estrago feito rsrsrs, entendi, é melhor ter um trabalhão para refazer do que ter um trabalhão todo santo dia.
Responder

Gostei + 0

04/08/2014

Alan Mario

de nada Valquiria, sobre as novas duvidas, não estou apto a te responder.
Responder

Gostei + 0

05/08/2014

Alex Lekao

o retrabalho sempre da mais trabalho que o trabalho. kkkk

ficou parecendo coisa de filosofo louco... mas tudo bem. kkk

dependendo estrago feito rsrsrs, entendi, é melhor ter um trabalhão para refazer do que ter um trabalhão todo santo dia.
Responder

Gostei + 0

05/08/2014

Alex Lekao

Oi Honestamente nao entendi muito bem. rsrsr

se entendi bem, se ha necessidade de tantos campos assim para ter uma chave primaria, talvez seja necessario se pensar na divisao da tabela e usar apenas o relacionamento comum.

como nao sou a pessoa mais experiente no assunto, nao conseguirei ajudar bem, desculpe.

Obrigada pelas opiniões.

Estou fazendo um projeto para Firebird.
Uma outra dúvida que me ocorre, é na criação das chaves primárias no caso do relacionamento entre as tabelas, como conseguir boa performance e integridade referencial?
Por exemplo já vi tabelas com até 4 campos formando chaves primárias e todas as tabelas "detalhes ou filhas", carregando estes mesmos campos, no final um custoso e enorme join.

Seria mais eficiente criar apenas um campo "ID" como chave ? Se sim como referenciar os relacionamentos?

Agradeço qualquer ajuda.
Responder

Gostei + 0

05/08/2014

Mariana Carvalho

o retrabalho sempre da mais trabalho que o trabalho. kkkk

ficou parecendo coisa de filosofo louco... mas tudo bem. kkk

dependendo estrago feito rsrsrs, entendi, é melhor ter um trabalhão para refazer do que ter um trabalhão todo santo dia.


ficou mesmo rsrsrsrs.
Responder

Gostei + 1

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar