> 2 coisas que faltaram dizer: > a) o mendigo acabou de ganhar 10 milhoes na loteria
É bom ele arrumar um CPF, senão não recebe o prêmio. > b) não podemos deixar de lembrar da questão de encoding, tamanhos em byte do > char e etc. ? >> O fato de um dado não existir previamente nos dados de negócio não >> significa ser artificial e tampouco o contrario é verdadeiro. CPF e CNPJ são >> dados artificiais sob os quais se aplicam regras para garantir integridade >> "chave primaria". O uso de CPF como chave primária é discutível em termos de negócio, não de banco de dados. Se uma determinada aplicação precisa que uma pessoa esteja obrigatóriamente cadastrada com CPF, o CPF pode ser sim a chave primária porque ele é garantidamente único e obrigatório pelo *negócio*. Por outro lado, para fins de auditoria e compliance, o CPF não deve de forma alguma ser utilizado como chave primária, pois trata-se de dado sensível que pode ter de ser "escondido" em determinadas partes da aplicação e, até mesmo em alguns casos, do DBA (por isso desde o PostgreSQL 8.4 temos permissões diferenciadas por coluna). Às vezes tem até de ser criptografado. Portanto, pra finalizar, é melhor ter um campo serial gerando códigos para um cadastro de pessoas. >> Se voce estabelecer, por exemplo, que um sistema de emprestimos tera >> como das pessoas o CPF e entrar um mendigo, sem CPF, querendo fazer uma >> aplicação ele sera barrado pela questão de que ele não tem um documento sem >> o qual o sistema não funciona? ou, rapidamente surgira um "numero de >> documento"? Não se empresta dinheiro em lugar algum sem ter um CPF. Mesmo mendigos. Não confunda mendigo com indigente. >> Afora que trabalhar com chaves desse tipo, ou pior, tomar valores reais >> na composição de chaves compostas dificulta a lida desse modelo quanto >> portado para a programação e dá mais trabalho de indexação do que um serial. >> Por exemplo, levando em conta que use um domain com o tipo de dado char(11), >> ao inves de um bigint, talvez existam mais páginas de indice por que a >> entrada do indice é maior, e isso seria o inicio de um efeito cascata quando >> essa mesma chave tiver de ser usada como estrangeira em outras tabelas, >> o que me leva a ultima parte da sua frase, de juncoes desnecessarias. Não entendi sua relação entre o tipo de dado e a quantidade de junções nas consultas. Também já foi dito várias vezes aqui que não há relação direta entre performance com dados do tipo char ou integer. A única afirmativa é que, usando char, ocupará mais espaço dentro da página e, talvez, em disco no fim das contas. >> Não vejo como o uso das chamadas "chaves reais" vai melhorar a questão de >> junções. Se eu tenho uma chave e preciso buscar um dado em outra tabela, >> para traze-lo eu devo ou inserir a requisição dos dados na mesma query ou >> fazer uma nova requisição usando a chave como parametro. Não vejo nenhuma diferença pra fins de consulta, independente do campo que usar como chave primária ou estrangeira. A quantidade de junções será a mesma. O número de tabelas é que conta. >> Muito bem suposto o comportamento de que uma chave primaria, quando >> utilizada em outra tabela, digamos, 1:1, vai provavelmente estar na mesma >> página de indice (?) e isso seria interessante para acelerar a recuperação >> dos dados, e isso vai de encontro com as informações que estão presentes no >> catalogo do sistema sobre os indices, que irão acelerar a busca. Também não vi esta relação. Estar na mesma página de dados ajudaria atualizações e não buscas, até porque quando tratamos de chaves normalmente estaremos trabalhando com índices. Em caso de seqscan, a tabela toda é varrida de qualquer forma, dados na mesma página ou não. Veja a relação entre dados na mesma página e atualizações em [1], fillfactor. Ah, o uso de fillfactor baixo torna as tabelas maiores. [1] http://www.postgresql.org/docs/9.0/static/sql-createtable.html []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
