Re: [pgbr-geral] RES: RES: Chave Primaria Composta
2016-08-25 15:31 GMT-03:00 Márcio A. Sepp : > >> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha >> ou "neta" da tabela. > > Gostaria de citar um exemplo prático: […] > 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? Não vou criticar não, para mm está bom. É isso aí. > 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. Testar e experimentar sempre é bom, mas o que estamos falando já foi verificado à exaustão — além de decorrer do próprio modelo relacional e conceitos decorrentes. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: Chave Primaria Composta
> 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
[pgbr-geral] RES: RES: Chave Primaria Composta
> Márcio, quando for citar algo que alguém mais escreveu, marque para > evitar confusão. Desculpe, consegui acertar agora meu leitor de emails pra isso... tempo já que tava procurando. > > > Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A > > meu ver, justamente vc colocando mais atributos na chave primária > deveria deixar as consultas mais rápidas (se vc utilizar os campos da > chave no where) e, como consequencia, talvez iria utilizar mais o disco > para armazenamento (falando a grosso modo). > > Não. > > Os atributos de uma chave por definição já existem no disco. A rigor, > é a chave artificial, apesar de poder ser simples, que representa > desperdício, visto que tem de ser definida (incluindo índice) além das > chaves naturais (nunca as substituindo!), sejam estas compostas ou > simples. > > A eventual economia de armazenamento seria para o caso de tabelas > ‘pai’, que ‘exportariam’ apenas um atributo para as ‘filhas’. Mas essa > economia geralmente é mais que contrabalançada por haver índice e > atributo adicional nas tabelas pais, e pelo fato de que chaves > artificiais quase sempre exigem mais junções, visto que as chaves > estrangeiras nas tabelas filhas não contém informações úteis; e pelo > fato de que geralmente as pessoas acabam não definindo chaves naturais > quando definem as artificiais, o que gera, além de inconsistências, > necessidade de tratar integridade na aplicação, o que é muito > ineficiente. Exato. Tenho visto bastante a utilização de "id" pra tudo. Consequentemente grande lentidão e falta de integridade. > Não entendi, comentar o quê? Sem os significados, e o resto da > estrutura e explicações, é impossível dizer qualquer coisa. Modelagem > de dados é o tipo de coisa muito difícil de fazer remotamente > justamente pela quantidade de informações necessárias. Viche... desculpe. Essa parte não era pra ter ido na verdade... > Em termos gerais, amiúde uma chave composta grande pode indicar falta > de normalização, e portanto ou desatenção de quem modelou, ou > desconhecimento — geralmente as pessoas entendem mal as formas normais, > e até desconhecem qualquer coisa além da 3NF. Só para lembrar, há sete > formas normais (as 5NFs originais, a Boyce-Codd e a temporal, esta de > difícil aplicação), mas geralmente o bom senso e uma análise atenta dá > bons resultados mesmo conhecendo apenas as três primeiras formas > normais. > > Mas de fato há situações em que uma chave pode chegar a cobrir todos os > atributos (naturais) de uma relação (não confundir com relacionamento). Da minha parte, Dutra, hoje vc sanou todas as dúvidas que eu tinha. Tempos atrás, quando eu havia questionado pela primeira vez, não havia ficado claro e não me senti a vontade pra voltar a lista. Hoje está perfeito! Obrigado a todos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
