2016-08-25 13:30 GMT-03:00 Márcio A. Sepp <mar...@zyontecnologia.com.br>: > > Depende, lá como eu disse as chaves compostas foram usadas de forma errada
[…] Márcio, quando for citar algo que alguém mais escreveu, marque para evitar confusão. > 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. > Este assunto eu já havia levantado aqui na lista um tempo atrás e eu tbm > tenho dúvidas em relação a quantidade de campos na chave. Justamente nesta > parte mais baixa da contabilidade eu cheguei a 9 campos na chave da tabela de > movimentação por projeto. Tbm achei estranho isso, pois nunca havia visto uma > chave primária tão grande... > > No meu caso a chave está assim: > character varying(10) > bigint > smallint > smallint > smallint > integer > character(1) > integer > integer > > Não coloquei os nomes dos campos pq eles seguem um propósito próprio e teria > de colocar uma legenda pra eles e não é o propósito. 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. 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). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/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
