Em 28 de abril de 2015 20:29, Matheus Saraiva <matheus.sara...@gmail.com>
escreveu:
> Pois é, vejo que, em parte, eu meio que entendia errado essa "critica"
> às chaves artificiais.
> Hoje mesmo quando enviei a primeira pergunta eu me referia ao uso de
> chaves naturais compostas em relacionamentos, ou seja, como chaves primárias.
Sim, seria o ideal, pelo menos na ausência de separação de modelos lógico e
físico.
> Eu me
> refira justamente a uma modelagem sem chaves artificiais, onde os
> campos que compunham as chaves primárias são replicados nas outras tabelas.
E é o que eu dizia que geralmente não é problema algum.
> Esse tipo de modelagem acredito ser complicado em requisitos de
> hardware limitados principalmente por alguma restrição de armazenamento.
É essa crença que se constitui em (falsa) otimização precoce, que como todos
sabemos é raiz de toda sorte de males.
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.
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.
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
);
CREATE TABLE public.bairro
(
codpais integer NOT NULL,
coduf integer NOT NULL,
codcidade integer NOT NULL,
bairro character varying(50) NOT NULL,
PRIMARY KEY (codpais, coduf, codcidade, bairro),
FOREIGN KEY (codpais, coduf, codcidade) REFERENCES cidade (codpais, coduf,
codcidade) ON UPDATE CASCADE ON DELETE NO ACTION
);
CREATE TABLE public.rua
(
codpais integer NOT NULL,
coduf integer NOT NULL,
codcidade integer NOT NULL,
bairro character varying(50) NOT NULL,
rua character varying(50) NOT NULL,
PRIMARY KEY (codpais, coduf, codcidade, bairro, rua),
FOREIGN KEY (codpais, coduf, codcidade, bairro) REFERENCES bairro (codpais,
coduf, codcidade, bairro) ON UPDATE CASCADE ON DELETE NO ACTION
);
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? Não seria menos custoso criar uma
chave artificial na tabela "rua" para ligar com a tabela de pedido?
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.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
