Em 25 de maio de 2011 23:18, Flavio Henrique Araque Gurgel <fha...@gmail.com > escreveu:
> > 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. > A questão aqui não tem nada a ver com mendigo ou indigente. O exemplo foi dado simplesmente para mostrar que seja lá qual valor adicional seja visto no uso de chaves naturais ao contrario de artificiais ele não vale a escolha. prefiro o uso de seriais(não confundir com cereais) > > >> 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. > Eu também não entendi a premissa anterior para a qual escrevi esta explicacação, ou melhor, eu a entendi bem... e cheguei a mesma conclusão que voce, ou seja, não importa se um dado natural ou artificial, ele vai implicar na mesma quantidade de juncoes ou operações de request. > 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. > Se eu não me engano, minha explicação faz exatamente esta relação entre o tipo de dado de um campo de indice e o numero de paginas que ele tem no final, fazendo diferença, mesmo que não significativa, no processo de localização de valores. Talvez eu não tenha conseguido ser claro na resposta, mas achei que "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" se referia exatamente a isso. > > >> 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. > Acho que concordamos nesse ponto, é isso? > > >> 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. > Eu fiz uma suposição, vide " Muito bem suposto...", na qual me apoio na ideia de que não importanto qual o tipo da chave, se a relacao entre tabelas for de 1:1, os valores estarão na mesma página e poderiam, veja, poderiam ser relacionados e acelerar dessa maneira a busca. Mas veja, sua observação de que ajuda em atualizações ao inves de buscas me deixou interessado em seu aproach, haja visto que voce só vai chegar a seqscan depois do plano de execução perceber que você esta utilizando os valores errados para localizar o registro, o que nunca vai acontecer se voce utilizar a primary key (me corrija se eu estiver errado) e pode acontecer se voce estiver utilizando "chaves reais compostas", por exemplo, de 3 campos, e resolver localizar o registro somente pelo 2o ou 2o e 3o campo. Quanto ao parametro de fillfactor, não vi a relação dele com minha observação, a não ser, realmente, em caso de update, porém, fica claro que o uso dele beneficia tanto atualizações quanto buscas, e não somente atualizações, como foi sua explicação. Espero ter explicado melhor minhas observações. > > [1] http://www.postgresql.org/docs/9.0/static/sql-createtable.html > > []s > Flavio Gurgel > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Ivo Nascimento - Iann ------------------------------------------------- http://about.me/ivonascimento -------------------------------------------------
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
