2008/7/20, Ribamar Sousa <[EMAIL PROTECTED]>:
> Olá!
>
> Estou precisando de ajuda para fazer uma consulta update que traz os
> registros de duas tabelas para uma terceira.
>
> Tenho uma tabela com os CEPs do Brasil (633401 registros), com a seguinte
> estrutura:
>
> create table ceps
> (
>     cep char(8) primary key,
>     tipo char(72),
>     logradouro char(70),
>     bairro char(72),
>     municipio char(60),
>     uf char(2)
> );
>
> Tenho outra logradouros (contém 316499 registros):
>
> create table ceps
> (
>     logradouro int primary key,
>     logradouro char(70)
> );
>
> E tenho a tabela de ceps normalizada:
>
> create table cepsn
> (
>     cep char(8) primary key,
>     tipo int,
>     logradouro int,
>     bairro int,
>     municipio int,
>     constraint tipo_fk foreign key (tipo) references tipos(tipo),
>     constraint logradouro_fk foreign key (logradouro) references
> logradouros(logradouro),
>     constraint bairro_fk foreign key (bairro) references bairros(bairro),
>     constraint municipio_fk foreign key (municipio) references
> municipios(municipio)
> );
>
> Quero dar um update na tabela cepsn trazendo os códigos da logradouros
> (campo logradouro) mas respeitando o cep correspondente da tabela ceps.
> Estou fazendo assim, mas está demorando demasiado. Mais de 2 horas e a
> consulta não terminou (PostgreSQL-8.2.7, Ubuntu 8.04, Senpron 1.86, 1GB
> RAM).
>
> Quem quizer ver o relato completo e com mais detalhes, acesse:
> http://pg.ribafs.net/content/view/28/30/
>


Só uma dúvida:
Por que considerar logradouro como uma tabela separada?
Aparentemente você considera que existe uma dependência funcional mas,
sob meu ponto de vista, tal dependência não existe, isto é, o fato de
existirem logradouros com o mesmo nome em diferentes municípios não
caracteriza uma dependência.
É possível que um mesmo logradouro possua diferentes CEPs mas, neste
caso, existe uma condição adicional, por ex.: nºs pares: cep x, nºs
ímpares: cep y ou de nº n a m: cep x, de m a o: cep y etc. condição
esta que não está presente em suas tabelas.

Osvaldo
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a