Em 29 de abril de 2015 09:28, Márcio A. Sepp <[email protected]> escreveu: > > Deixa ver se entendi direito. Vou criar abaixo uma sequencia de tabelas > utilizando chaves naturais e farei a ligação das tabelas de cadastro com uma > tabela de pedido por exemplo. > > CREATE TABLE public.pais > ( > codigo integer, > nome character varying(50) NOT NULL, > PRIMARY KEY (codigo) > ); > // o código do país é obtido em catálogos internacionais de países (acho que > o FEBRABAN o outro órgão disponibiliza). Então é um código associado a estas > lista.
Essa é uma possibilidade. Outra é usar o código ISO. Vai depender de tua situação, mas o ISO tem a vantagem de ser legível (BR para Brasil, por exemplo) e já atender algumas necessidades de usuário, evitando junções. Só vi esse código numérico sendo usado em ambiente bancário (financeiro), mas creio que deva ter outros usos também. > CREATE TABLE public.uf > ( > codpais integer NOT NULL, > coduf integer NOT NULL, > sigla character(2) NOT NULL, > descricao character varying(50) NOT NULL, > PRIMARY KEY (codpais, coduf), > FOREIGN KEY (codpais) REFERENCES pais (codigo) ON UPDATE CASCADE ON DELETE > NO ACTION > ); > > // O código da UF tbm é fornecido por algum órgão, no caso o IBGE. O mesmo > ocorre com o código da cidade abaixo. Idem, código numérico é uma possibilidade mas a sigla (DF para Distrito Federal, por exemplo) serve perfeitamente para a maior parte dos usos, de novo evitando junções. Veja também que, usando o numérico, sigla ainda é uma chave candidata que vale a pena declarar. Mais uma vez, só vi esse código numérico sendo usado em bancos financeiros, mas creio que tenha outros usos. > CREATE TABLE cidade > ( > codpais integer NOT NULL, > coduf integer NOT NULL, > codcidade integer NOT NULL, > nome character varying(50) NOT NULL, > CONSTRAINT cidade_pkey PRIMARY KEY (codpais, coduf, codcidade), > CONSTRAINT cidade_codpais_fkey FOREIGN KEY (codpais, coduf) > REFERENCES uf (codpais, coduf) MATCH SIMPLE > ON UPDATE CASCADE ON DELETE NO ACTION > ); Aí, sim, faz perfeito sentido. Você pode até declarar uma ‘chave’ artificial se tiver reais (não imaginados) problemas de desempenho para usar como primária, mas não pode deixar de declarar essa chave natural mesmo que como UNIQUE. Só que, como explanado acima, para um caso geral (sem requisitos em contrário) eu preferiria usar as siglas ISO para país e UF. […] > CREATE TABLE public.pedido > ( > codpedido serial NOT NULL, > codpais integer NOT NULL, > coduf integer NOT NULL, > codcidade integer NOT NULL, > bairro character varying(50) NOT NULL, > rua character varying(50) NOT NULL, > numero integer, > PRIMARY KEY (codpedido), > FOREIGN KEY (codpais, coduf, codcidade, bairro, rua) REFERENCES rua > (codpais, coduf, codcidade, bairro, rua) ON UPDATE CASCADE ON DELETE NO ACTION > ); > > Se esta tabela de pedido tiver, digamos que 10.000 pedidos/dia. Qual o > inchaço que irá representar criando-a desta forma? Isso você calcula facilmente. Mas não é inchaço, é uma informação útil que evitará muitas junções e atualizações de índice (toda atualização de índice é duplicada quando se usa ‘chave’ artificial: uma vez na chave natural, outra na artificial). > Não seria menos custoso criar uma chave artificial na tabela "rua" para ligar > com a tabela de pedido? Não, no caso geral. Sim, se você tiver pouquiíssimo espaço em disco e puder esperar por todas as junções. Na dúvida, ou teste, ou evite a otimização precoce até constatar a necessidade real. E aí teste para ver se a perda de desempenho será aceitável. > Em contrapartida, digamos que é imprescindível que o banco de dados forneça a > informação de quanto foi feito de pedido por rua, bairro, cidade, uf e país. Mensagem truncada, ou meu cérebro ainda não acordou? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:[email protected] +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:[email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
