> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha > ou "neta" da tabela. > Mas assim, no que eu vi, na prática é o seguinte: > 1 - A informação da chave, geralmente não é a que vc quer, então o join vai > acontecer igual
Gostaria de citar um exemplo prático: Criar estrutura de 03 tabelas conforme entendido hoje na explanação do Dutra e do Tiago. -- Tabela do lote contábil CREATE TABLE public.lote ( documento character varying(20) NOT NULL, data date, PRIMARY KEY (documento) ); -- Tabela de lançamentos contábeis CREATE TABLE public.lancamento ( documento character varying(20) NOT NULL, conta integer NOT NULL, natureza character(1) NOT NULL, valor numeric(10,2) NOT NULL, PRIMARY KEY (documento, conta, natureza), FOREIGN KEY (documento) REFERENCES public.lote (documento) ON UPDATE CASCADE ON DELETE NO ACTION ); (veja bem, a intenção aqui não é discutir o meu entendimento da contabilidade, é apenas mostrar um desenho ficticio de uma aplicação. Na prática pode e talvez deva ser diferente a estrutura) -- Lançamento no centro de custo CREATE TABLE public.lancamentoccu ( documento character varying(20), conta integer, natureza character(1), codigo_ccu integer, valor numeric(10,2) NOT NULL, PRIMARY KEY (documento, conta, natureza, codigo_ccu), FOREIGN KEY (documento, conta, natureza) REFERENCES public.lancamento (documento, conta, natureza) ON UPDATE CASCADE ON DELETE NO ACTION ); Neste modelo, se eu quiser saber o total que foi debitado de um centro de custo em um determinado mês eu não preciso envolver a tabela de lançamento, pois a data está na tabela lote e o restante da informação que eu preciso está na tabela de lancamentoccu. (Não sei se essa prática é boa ou não... por favor, comentem...), mas que é possível é... Agora, se eu tiver id em todas as tabelas, necessariamente será preciso passar por todas elas para chegar onde está a informação. Aí sim aumenta *muito* o tempo. > 2 - Os índices ficam bem maiores Sim. Porém no mesmo modelo acima, se eu não utilizasse chaves naturais eu teria de fazer da seguinte forma: -- Tabela do lote contábil CREATE TABLE public.lote ( id integer serial, documento character varying(20) NOT NULL, data date, CONSTRAINT PRIMARY KEY (id), CONSTRAINT UNIQUE (documento) ); Observe que tem de criar o campo id a mais (que tbm consumirá espaço) e uma constraint no campo documento (que tbm consumirá espaço). Já nas outras tabelas vc terá de, além de criar um campo a mais (id), também terá de criar uma fk pra tabela pai. Na tabela lancamentoccu a coisa fica pior ainda, pois vc precisará também criar uma referência para a tabela lote. Caso contrário vc sacrifica a integridade da aplicação. Por favor, Dutra, Adami e demais... critiquem as minhas afirmações acima? > 3 - Vc tem uma redundância de informações e maior consumo de espaço > 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que você > precise unir 30 tabelas cada uma com 10 campos na sua chave, > pense no > tamanha da instrução. > O sistema em questão que eu citei anteriormente tem todos esses problemas e > hoje é um verdadeiro elefante branco. O que daria também pra gente fazer é criar um banco de testes e verificar como ficam as coisas após uma certa carga. Daí mata isso de vez. _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
