2012/2/17 Fernando Franquini 'capin' <fernando.franqu...@gmail.com>: > > Vou ver se consigo criar uma síntese da nossa discussão:
Ótimo. > Em geral, o que me parece que está 'pegando' é em relação ao código sem mais > restrições que garantam a unicidade. Exato. Na verdade, é esse, digamos, meu limite: com bons argumentos, aceito tudo, menos sacos (tabelas sem nenhuma chave natural). > Pois ai nesse caso podemos ter > 'repetição exagerada' de informações. Toda repetição já é um exagero, não? ;-) > Mas caso tenhamos em CLIENTES o CPF, > me parece que melhora consideravelmente. Desde que, de fato, o cliente precise informar o CPF, o que amiúde não é o caso. Uma situação relativamente comum é não haver uma única chave natural. Digamos, por exemplo, que na mercearia da esquina o cliente possa ser identificado por um nome, um apelido, ou uma descrição como ‘o perneta’, ‘a loira oxigenada’ ou algo assim — acreditem, na vila natal de meu pai é assim. Poderíamos gambiarrar, dizendo que nome, apelido ou descrição são todos a mesma coisa. Uma solução mais elegante poderia ser atributos separados com valores especiais. Por exemplo, a seqüência vazia de caracteres; a chave seria composta de nome, apelido e descrição. No limite, a chave natural pode ser todos os atributos, menos os que componham a chave artificial. Mas é melhor evitar essa situação, se possível. Às vezes, acontece algo assim numa tabela de logs, por exemplo. > Então me parece que ficou de mais importante nisso é a questão de que > nos SELECT com JOINS para ambos os casos quando necessários terá a mesma > performance. É isso? Do ponto de vista de desempenho, na grande maioria dos casos, sim. > E quanto a questão da generalização, realmente aqui um outro grande problema > dos sistemas, e muitas vezes nossos :D Por isso a tentação dos geradores de código… mas esse é outro assunto. _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
