No seu caso, não utilizaria chave natural e sim criaria uma chave artificial para controlar isso, tbem insira o (id) da cidade o volume de dados sera menor pra coluna
Em 08/12/2011 23:04, "Vinicius Santos" <[email protected]> escreveu: > > Pessoal, boa noite, > > Estamos mudando algumas coisas no controle de estoque de nosso ERP, que já está em funcionamento, porém algumas modificações eu quero usar chaves naturais, e estas chaves são compostas. > > Aqui demonstro um exemplo simples e fictício, em que a tabela "deposito_produtos" tem uma chave natural. ( Sei que não tem a UF, para colocar junto com a cidade, mas é apenas um exemplo bobo ) > > CREATE TABLE deposito_produtos( > nome VARCHAR( 50 ) NOT NULL, -- nome do deposito > cidade VARCHAR( 50 ) NOT NULL, -- cidade onde fica o deposito > tamanho_deposito NUMERIC NOT NULL, -- Tamanho do deposito em m² > PRIMARY KEY ( nome, cidade ) > ); > > CREATE TABLE produtos( > descricao VARCHAR( 50 ) PRIMARY KEY, -- Nome do produto > nome_deposito VARCHAR( 50 ), -- Referência da tabela deposito_produtos > cidade VARCHAR( 50 ) -- Referência da tabela deposito_produtos > ). > > Minha dúvida é a seguinte: Se eu tivesse usado uma chave artificial na tabela de "deposito_produtos", eu não precisaria exportar duas colunas para a tabela "produtos", apenas a chave artificial. Então eu garantiria unicidade com um UNIQUE CONSTRAINT. > > Se eu fizer uma consulta de todos os produtos e precisar fazer um JOIN com "deposito_produtos" para saber o tamanho do deposito, o JOIN envolveria 2 colunas de cada tabela. > Se fosse uma chave artificial seria apenas uma. > > Seria justificável o uso de chaves artificiais nestes casos ? > > Obrigado. > > _______________________________________________ > 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
