> > Exatamente esse o mais grave problema das chaves artificiais: obscurece o > modelo e gera código de péssima qualidade, principalmente quando o > programador original não é mas o único. >
Adicionado: Sem falar na imundice do dado gerado em tabelas sem critério de unicidade negocial. Serial não garante qualidade do dado nem tampouco qualidade da informação. Mas isso é assunto pra outro tópico ;) 2011/5/13 Gmail <[email protected]> > ----- Message d'origine ----- > > Se eu fizer explicito e tiver que adicionar o campo na tabela e no meu > > select, vou ter que examinar o codigo da mesma forma. > > Mas, se acrescentar um atributo numa relacão, muitas vezes não precisará > alterar o código que não usa o novo atributo. Com o asterisco, sempre > precisará alterar. > > > na minha necessidade estou montando em grid dinamico em php > > atravez de uma função, então fica fácil dar manutenção. > > Não sabia disso. Na ausência de informacões, sempre damos a melhor prática > genérica. E ela inclui lembrar que o aplicativo é efêmero, os dados são > permanentes. Hoje teu dado é usado em PHP, amanhã pode ser Lisp; hoje é uma > matriz dinâmica, amanhã haverá mil outros usos. > > > > gosto de usar > > “serial” porque ele me poupa muito tempo de ficar criando chaves > > Exatamente esse o mais grave problema das chaves artificiais: obscurece o > modelo e gera código de péssima qualidade, principalmente quando o > programador original não é mas o único. > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Forte abraço, Aldemir Vieira Salvador.Ba.Br <[email protected]> ==
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
