Em outra mensagem você colocou "Não é simples demais para uma tabela que
terá milhões de registros ???"...
O problema não é simplicidade. Na verdade, simplicidade geralmente é a
melhor prática!
O pessoal aqui falou sobre a "tal" Chave Natural... mas o que vem a ser uma
chave natural??
Durante o processo de modelagem, identificamos atributos ou combinação de
atributos que identificam cada ocorrência (registro) como único. Cada uma
dessas combinações é conhecida como chave candidata. As chaves candidatas
identificam a ocorrência como única, mas precisamos eleger uma delas como
chave primária.
Vamos pegar como exemplo a provável entidade "pessoa_fisica" abaixo:
create table pessoa_fisica (
id_pessoa
cpf
nome
pai
mae
... )
Dentre os atributos acima, podemos eleger como candidatas os atributos
"id_pessoa" e "cpf".
"Cpf", neste caso é a chamada "chave natural", visto que a mesma foi
introduzida pelo usuário e diz respeito ao negócio, já "id_pessoa" é
uma chave artificial, que é controlada pelo banco e não diz respeito ao
negócio, por isso ser "artificial". Mas qual a melhor escolha?
Existem várias vantagens e desvantagens associadas à essa escolha. Muitas
vezes, isso levando-se em conta chaves compostas, chaves artificiais
economizam espaço nos índices e nas colunas quando repassadas a FKs e chave
naturais costumam economizar em JOINs (se repassamos a chave natural para
outras tabelas, talvez não precisemos fazer um JOIN) e principalmente no
fato de conter em si uma informação da tupla, ou seja, ela diz exatamente o
que é e a que serve.
Em todo caso, um dos grandes dilemas entre chaves artificiais e chaves
naturais é a volatilidade de tuas regras de negócio. Se você escolhe uma
chave natural e hoje a combinação dela é única, o que fazer com o seu modelo
de dados se amanhã ela não for unica? Seria muito ruim sair "remendando" o
modelo.
Logo, na minha humilde visão, não incluiria os termos "certo" e "errado" em
se utilizar uma chave natural em detrimento de uma chave artificial, mas
sim, ao teu modelo de negócios o que é melhor? Na maioria dos casos, chaves
naturais são a melhor escolha, mas como maioria não significa todos, você
deve rever teu modelo de negócios e claro, dar uma boa estudada nos
conceitos e processos envolvidos em modelagem de dados.
Att,
--
Charly Batista
Administrador de Banco de Dados
http://javadevilopers.blogspot.com/
[email protected]
Linux user #391083
"Se você tem uma maçã e eu tenho uma maçã e nós trocamos essas maçãs, então
eu e você ainda teremos uma maçã cada. Mas se você tiver uma idéia e eu
tiver uma idéia e nós trocamos idéias, então cada um de nós terá duas
idéias."
George Bernard Shaw (1856-1950)
Em 28 de outubro de 2010 00:19, Emerson Moretto <[email protected]>escreveu:
> 260.000 é piada para o PostgreSQL, mesmo para realizar buscas.
>
> Eu trabalho com um banco com 46 milhões de registros em uma única
> tabela usando PostgreSQL. Não é o banco principal, é de redundância,
> mas ele aguenta muito bem, desde que com índices bem feitos.
>
> No meu caso:
>
> - Desnormalizei tudo, usei tudo em uma única tabela e não faço nenhum
> join. (sim, repliquei colunas.. campos vazios... etc)
>
> - Separei os campos principais de buscas em mais de um campo. E
> coloquei índice para todos esses campos. Ex: nome_completo ->
> primeiro_nome, ultimo_nome.
>
> Então,
> # select * from tabela where primeiro_nome = 'Jose' and ultimo_nome =
> 'Silva';
> de certa forma, fica como se fosse um like e ao mesmo tempo com muito
> desempenho.
>
> - Criei esses índices de nomes usando o próprio valor do campo no
> índice. O PostgreSQL por default faz um hash do valor para melhor uso
> de memória e a comparação.
>
> Pra fazer isso:
> # create index idx_nome on tabela (nome varchar_pattern_ops);
>
> Esse varchar_pattern_ops que faz isso acontecer
>
> Com isso, a consulta:
> # SELECT * FROM tabela WHERE nome LIKE 'JOS%'
> utiliza o índice para fazer o LIKE.
>
> Dessa forma, a busca será muito rápida (te garanto, no meu caso ficou
> em ~25 ms), mas esse LIKE só vai funcionar para quando a busca iniciar
> com determinado valor. LIKE '%ANA%' ou LIKE '%ANA' vão funcionar, mas
> fazendo full scan.
>
>
> Enfim, tudo que fiz nesse meu case escrevi nesse post:
> http://www.emersonmoretto.com/articles/tag/postgres%209
>
> * Não sou especialista em PostgreSQL, apenas admiro, defendo e uso
> desde a versão 7.2
> ** Espero ter ajudado e não ter te confundido mais
>
>
> att
> Emerson Moretto
>
>
> 2010/10/27 Listas <[email protected]>
> >
> >
> >
> > Olá Pessoal,
> >
> > Sou programador em PHP e utiliso o mysql para fazer meus sistemas,
> >
> > bom, estou desenvolvendo um sistema on-line de uma lista telefonica e
> resolvi usar o postgresql como banco de dados.
> >
> > Porém, estou com dúvidas de como fazer a tabela no banco.
> >
> > A tabela va conter de arrancada 260.000 registros
> >
> > Vai ser um cadastro normal de usuario, como ( Id, nome, endereço, cep,
> cidade, estado, anuncio, etc )
> >
> > Gostaria de saber como criar esta tabela, a estrutura, tipo
> auto_increment, ja que esta tabela vai ser imensa e terá que fazer buscas
> rápidas.
> >
> >
> > Alguem poderia me ajudar ???
> >
> >
> >
> >
> >
> > _______________________________________________
> > pgbr-geral mailing list
> > [email protected]
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
>
>
>
> --
> []s
> Emerson G Moretto
> [email protected]
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
