[firebase-br] Normalização de Banco de dados

[Gestão Comercial]

Daniel,

Já trabalhei com vários bancos, e com os tres tipos de sistemas de chaves -
com todos os campos necessários, somente com um campo,  e com sistemas
mistos - e penso que o que deve ser levado em consideração, no momento da
escolha de como montarás tuas chaves, é a questão dos acessos, consultas, ao
banco.

Veja da seguinte maneira:

1. Uma tabela que tenha, por exemplo 4 campos na PK, significa provavelmente
que são os campos das regras de negócio, e são o que o usuário do sistema
conhece. Nesta situação, a maioria dos acessos deverá ser realizado usando
estes campos, ou pelo menos parte deles. Criar uma PK única para esta tabela
não fará sentido, pois o índice que terás necessidade também deverá ser
único. Ou seja, terás dois índices na tabela, e um deles com pouco uso
efetivo. Nesta situação, costumo ter a PK com os campos, e o índice como um
auxiliar para outras tabelas filhas ou relacionadas.

2. Em uma tabela que poderia ter uma PK com 4 campos, mas cujo acesso será
sempre indireto, via um outro select, aí sim vejo vantagem em ter uma chave
PK que seja um tipo automárico, pois neste caso é completamente transparente
ao usuário.

3. Outro aspecto que deve ser considerado, é que estas chaves únicas
normalmente serão transparentes ao usuário, controladas internamente pelo
sistema, o que pode requerer cuidados adicionais no banco e na aplicação
para mantê-las.

4. Por último, e não menos importante, considere o aspecto que, comvárias
campos únicos, uma tabela que possua informação de várias outras, será
simplesmente um conjunto de vários "números aleatórios", e buscar alguma
informação nela pode ser algo dispendioso e complicado.

Espero ter ajudado.

Abraços

Agostinho

Em 29 de setembro de 2010 16:18, DanielN
<danieln.desenvol em supersoft.com.br>escreveu:

> Pessoal, boa tarde
> estamos re-estruturando nossos sistemas, e um dos pontos a serem avalizados
> é a estrutura do banco de dados, com isso surgiu uma dúvida, onde gostaria
> da opinião de vcs:
> hoje usamos a chave primária da tabela para identificar um registro, em
> muitos casos utilizamos dois ou três campos como chave para isso.
> mas alguma pessoas dizem que deveria ter um campo único para este fim, um
> id que irá identificar o registro.
> alguem tem experiência com os dois tipos de estrutura de bancos para me
> dizer quais os benefícios de se utilizar um id único ao invés de vários
> campos na chave primária?
>
> um detalhe que acho que deve ser importante, nosso banco de dados é de um
> ERP, onde existem mais atualizações de dados do que emissão de relatório,
> mas os relatórios sempre envolvem muitas tabelas para chegar nas informações
> necessárias.
> e o volume de dados sempre é grande por tabela, coisa de no mímino 100000
> por tabela, na maioria de nosso clientes.
>
> Grato
> Daniel Nicoletti
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>