Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Galera, estou realmente impressionado com a quantidade de respostas que esta thread alcançou!!! =) Agradeço a todos que compartilharam sua opniao a respeito, foi muito util para mim toda esta conversa, aprendi muito mais do que esperava. Tenho certeza que nao apenas eu, mas muita gente que tinha/ou venha ter esta duvida novamente, esta thread será um otima fonte de informação. Voltando ao caso: O meu modelo: Tabelas: log (dtsys: TIMESTAMPZ, body TEXT, ** usuario) usuario (login VARCHAR(30), senha VARCHAR(128), isativo BOOLEAN, email VARCHAR(100)) grupo (nome VARCHAR(30), descricao VARCHAR(128) grupo_usuario [M..M] (** grupo, ** usuario) Bem, a) Em LOG eu gravo tudo que o usuario faz, sendo assim esta tabela ficara muito grande rapidamente. b) Assim como LOG, outras tabelas tem USUARIO como atributo para marcar que aquele registro pertence/foi criado/etc pelo usuario X. c) Grupo so é usado no relacionamente GRUPO_USUARIO. d) Em quase 100% dos casos que envolva grupo, vou querer apenas o nome do mesmo. Com base nestes requisitos (AGORA, depois depois da discussao :)) decidi (ou acho) que: 1) Usuario: - Terá uma chave artificial ID (BIGSERIAL) - Terá um INDICE UNICO para LOGIN 2) NOME será chave primária da entidade GRUPO Sendo assim, resolvo: 1) Um relacionamento a menos quando eu quiser saber os grupos do usuario X 2) Um relacionamento a menos quando eu quiser saber os usuarios do grupo Y 3) LOG e outras entidadas deixarão de ocupar tanto espaço em disco quanto ocupariam com o uso de LOGIN como campo estrangeiro para USUARIO 4) Quando quiser saber o usuário de um LOG e outras entidades, terei de fazer um INNER JOIN com USUARIO. O que acham disto pessoal?? Abraços, -- Moisés P. Sena (Analista e desenvolvedor de sistemas WEB e mobile) http://www.moisespsena.com http://linux.moisespsena.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 22/02/2012 09:53, Moisés P. Sena escreveu: 1) Usuario: - Terá uma chave artificial ID (BIGSERIAL) - Terá um INDICE UNICO para LOGIN ... O que acham disto pessoal?? Acho que a não ser que você não venha a ter 9223372036854775807 usuários, não precisa usar este tipo. Eu utilizo o smallint já que eu não tenho sistemas com mais de 32700 usuários. Além disso, bigint utiliza 8 bytes para armazenar o valor enquanto smallint utiliza apenas 2. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Shander A microempresa é uma outra pessoa (Jurídica, pois possui CNPJ). 2012/2/17 Shander Lyrio shan...@nucleo45.com.br Em 17/02/2012 15:56, Guimarães Faria Corcete DUTRA, Leandro escreveu: Vamos simplificar os requisitos para facilitar. Concessionária de carros que tem clientes que são pessoas físicas e jurídicas. Para facilitar é obrigatório o cadastramento de todos os dados dos clientes antes de executar uma venda. Cara, isso não existe — mas, se fosse simples assim, CPF/CNPJ seria (uma) chave natural. Mas imagino que a realidade, como sempre, seja bem mais complicada… Por isso que eu insisto que forçar a procura de chaves naturais para tudo é improdutivo. Olhe que nem tocamos no fato de o cliente poder ter uma micro empresa, neste caso ele teria um CPF e CNPJ mas seria a mesma pessoa. Eita Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk: bromba...@gmail.com skype: fernandobrombatti work: +55 54 3218-6060 home: +55 54 3028-7217 mobile: +55 54 9189-7970 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
O número do pedido pode existir desde 2 séculos atrás, nem por isso deixa de ter sua importância atual. Alguém sabe como funciona o processo em praticamente todos os sistemas de gestão de grande porte? Ou em empresas organizadas? Primeiro alguém gera um pedido no sistema e vai até o Caixa para pagar. Ou seja, o vendedor cadastra o pedido com todos os itens que você deseja adquirir (pode ser até um mero parafuso) e o caixa emite a NF ou o CF com base no pedido XYZ gerado pelo vendedor. Já vi em uma grande rede varejista do Sul do País o vendedor gerar o pedido nos terminais com um sistema em CLIPPER e te entregar um papelzinho de uns 1,5 x 5cm com o número do pedido. Aí me dirigi ao caixa e só nesse momento a NF passou a existir. Já vi isso até em bodeguinhas de 2 vendedores. Vai da organizaçãoda empresa. Mudando de saco para mala, esse número importante ou não, é algo presente no dia-a-dia. Uns vão dizer que é chave natural outros que é chave artificial; mas é uma chave. Saindo dos pedidos e indo para as pessoas. A melhor chave, hoje, no Brasil, seria usar o CPF. Seria, pois (pasmem) ainda há pessoas que não possuem o dito documento. E como vamos migrar os dados se o vivente não possui CPF? Padronizar isso seria algo fácil se fosse planejado agora uma regra a ser obrigatória para todos os que fossem comprar água. Talvez, teríamos 90% de eficiência. Porque não usar o código para identificar a pessoa? Quer algo mais flexível e aderente do que esta forma? Se sei o nome completo da pessoa eu preencho. Se tenho o CPF eu preencho. Se tiver o RG eu preencho. Mas se eu não tiver o nome completo (a única referência que tenho é 'ZÉ') eu ponho o que conseguir. Funciona igual às fichas do século XIX, faço a minha venda e basta! Apesar da thread estar aquecida, acredito que ainda há opiniões e/ou exemplos a serem agregados. Apesar de se tratar de uma questão simples, há várias opiniões sobre o assunto. 2012/2/18 Alexsander Rosa alexsander.r...@gmail.com Em 17 de fevereiro de 2012 19:04, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: OK, concordamos com número de pedido. No caso de código de cliente, de fato, o uso de fichas numeradas mecanicamente não era tão comum quanto no caso dos pedidos. Mas o histórico é relevante? Na minha não tão humilde opinião, é interessantíssimo mas quase tão irrelevante quanto o papel em si. A questão é se o código, número ou seja‐lá‐o‐que‐fôr é necessário para a organização por causa de suas regras, métodos e requisitos, ou se é uma imposição do sistema informatizado; se for da organização, é uma chave natural a mais, e é, meio que por definição, boa; se for do sistema, é uma complicação a mais, uma chave artificial a ser evitada se possível. Pelas minhas observações, no comércio o número de pedido é necessário porque os comerciantes o usam há séculos, não por imposição do sistema informatizado. Conforme eu já demonstrei várias vezes, há mais de 100 anos os talões de pedidos numerados mecanicamente são usados em muitos estabelecimentos. Na minha opinião, número de pedido é sim uma chave natural -- pelo menos no comércio. No universo em que trabalho há décadas, empresas de atacado e varejo com um porte razoável, até hoje não vi uma única ocasião em que o número do pedido não existisse. Já vi cadastros de produtos em livros, já vi cadastros de clientes em fichários, já vi controles de entregas em planilhas, mas nunca vi um pedido sem um número. Quase sempre o talão vem numerado, mas já vi casos onde ele era carimbado. Procurem carimbo numerador no Google, é um carimbo que avança o número automaticamente. Talvez o armazém da esquina não use este número e anote os pedidos num pedaço de jornal, mas se ele tiver algum tipo de equipamento emissor de cupom fiscal (ECF), destes com lacre da SEFAZ, vai trabalhar com pelo menos 4 atributos que vêm gravados na EPROM do ECF (ou são obtidos pelo relógio interno): data de emissão, número da loja (4 dígitos), número do ECF na loja (3 dígitos) e número do cupom (COO, contador de ordem de operação, 6 dígitos). Estes 4 atributos formam a chave primária da entidade cupom fiscal e esta também é, na minha opinião, uma chave natural. Quando vocês comprarem algo num supermercado, procurem por estes 4 atributos, eles estão impressos em todos os cupons fiscais do Brasil. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk: bromba...@gmail.com skype: fernandobrombatti work: +55 54 3218-6060 home: +55 54 3028-7217 mobile: +55 54 9189-7970 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17 de fevereiro de 2012 19:04, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: OK, concordamos com número de pedido. No caso de código de cliente, de fato, o uso de fichas numeradas mecanicamente não era tão comum quanto no caso dos pedidos. Mas o histórico é relevante? Na minha não tão humilde opinião, é interessantíssimo mas quase tão irrelevante quanto o papel em si. A questão é se o código, número ou seja‐lá‐o‐que‐fôr é necessário para a organização por causa de suas regras, métodos e requisitos, ou se é uma imposição do sistema informatizado; se for da organização, é uma chave natural a mais, e é, meio que por definição, boa; se for do sistema, é uma complicação a mais, uma chave artificial a ser evitada se possível. Pelas minhas observações, no comércio o número de pedido é necessário porque os comerciantes o usam há séculos, não por imposição do sistema informatizado. Conforme eu já demonstrei várias vezes, há mais de 100 anos os talões de pedidos numerados mecanicamente são usados em muitos estabelecimentos. Na minha opinião, número de pedido é sim uma chave natural -- pelo menos no comércio. No universo em que trabalho há décadas, empresas de atacado e varejo com um porte razoável, até hoje não vi uma única ocasião em que o número do pedido não existisse. Já vi cadastros de produtos em livros, já vi cadastros de clientes em fichários, já vi controles de entregas em planilhas, mas nunca vi um pedido sem um número. Quase sempre o talão vem numerado, mas já vi casos onde ele era carimbado. Procurem carimbo numerador no Google, é um carimbo que avança o número automaticamente. Talvez o armazém da esquina não use este número e anote os pedidos num pedaço de jornal, mas se ele tiver algum tipo de equipamento emissor de cupom fiscal (ECF), destes com lacre da SEFAZ, vai trabalhar com pelo menos 4 atributos que vêm gravados na EPROM do ECF (ou são obtidos pelo relógio interno): data de emissão, número da loja (4 dígitos), número do ECF na loja (3 dígitos) e número do cupom (COO, contador de ordem de operação, 6 dígitos). Estes 4 atributos formam a chave primária da entidade cupom fiscal e esta também é, na minha opinião, uma chave natural. Quando vocês comprarem algo num supermercado, procurem por estes 4 atributos, eles estão impressos em todos os cupons fiscais do Brasil. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Le 2012-F-18 17h14, Alexsander Rosa a écrit : até hoje não vi uma única ocasião em que o número do pedido não existisse. Então pronto, é uma chave natural. Provavelmente a ser complementada com uma outra, complexa. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/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
[pgbr-geral] Fwd: Chave Primaria em VARCHAR
Devolvendo à lista discussão conduzida em privado… -- Forwarded message -- From: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org Date: 2012/2/17 Subject: Re: [pgbr-geral] Chave Primaria em VARCHAR To: Fernando Franquini 'capin' fernando.franqu...@gmail.com 2012/2/17 Fernando Franquini 'capin' fernando.franqu...@gmail.com: Eu usaria da forma onde o Login seria sim uma Chave Natural, mas podendo ser Unique! Sim, mas para quê? Logo, preciso de um código para ser a PK e repassar isso as tabelas relacionadas. Exato, esse código é desncessário. Mas como tu diz que isso está errado, eu não vejo dessa forma. Eu digo um *monstrinho*, pois se eu tiver um login que é Email como PK, me parece que se tiver uns 4 ou 5 relacionamentos que você pode colocar no modelo (dependendo da solução), acho que pode começar a complicar as consultas, não? Pelo contrário, evita junções desnecessárias. Pois, se eu tiver uma PK varchar(100) para Email OU uma PK inteiro (ou outro menor) para um código, *ACREDITO* que joins com código seja mais eficientes, não? Não, como o Euler e o Flávio explicaram… pelo contrário, quando precisares do endereço de correio eletrônico, o que é uma situação bem comum, com o uso de chaves artificiais como o teu código precisarás de junções para recuperá‐lo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Leandro, agora eu consegui entender o seu ponto de vista. Então em resumo, sempre que eu tiver uma 'Unique' (dentro do meu ponto de vista onde PK é Código) eu poderia fazer isso que você está explicando e somente em casos aonde eu não teria um 'CONTROLE' natural eu poderia utilizar os CÓDIGOS para essas junções, seria isso? Podemos dizer também que isso seria ideal não somente para PostgreSQL, mas para a modelagem mesmo de BD podendo aplicar para qualquer banco de dados relacional? Obrigado pela atenção. capin 2012/2/17 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org Devolvendo à lista discussão conduzida em privado… -- Forwarded message -- From: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org Date: 2012/2/17 Subject: Re: [pgbr-geral] Chave Primaria em VARCHAR To: Fernando Franquini 'capin' fernando.franqu...@gmail.com 2012/2/17 Fernando Franquini 'capin' fernando.franqu...@gmail.com: Eu usaria da forma onde o Login seria sim uma Chave Natural, mas podendo ser Unique! Sim, mas para quê? Logo, preciso de um código para ser a PK e repassar isso as tabelas relacionadas. Exato, esse código é desncessário. Mas como tu diz que isso está errado, eu não vejo dessa forma. Eu digo um *monstrinho*, pois se eu tiver um login que é Email como PK, me parece que se tiver uns 4 ou 5 relacionamentos que você pode colocar no modelo (dependendo da solução), acho que pode começar a complicar as consultas, não? Pelo contrário, evita junções desnecessárias. Pois, se eu tiver uma PK varchar(100) para Email OU uma PK inteiro (ou outro menor) para um código, *ACREDITO* que joins com código seja mais eficientes, não? Não, como o Euler e o Flávio explicaram… pelo contrário, quando precisares do endereço de correio eletrônico, o que é uma situação bem comum, com o uso de chaves artificiais como o teu código precisarás de junções para recuperá‐lo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Franquini - Capin Graduado Bacharel em Ciencias da Computação - UFSC Analista de Sistemas e de Banco de Dados / DBA Contatos: fernando.franqu...@gmail.com / 048.9902.4047 Florianópolis - SC - Brasil http://franquini.wordpress.com/ http://franquini.wordpress.com/ http://br.linkedin.com/in/capin http://wf5.com.br/ http://twitter.com/dbacapin https://twitter.com/#!/dbacapin ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Fernando Franquini 'capin' fernando.franqu...@gmail.com: Então em resumo, sempre que eu tiver uma 'Unique' (dentro do meu ponto de vista onde PK é Código) eu poderia fazer isso que você está explicando e somente em casos aonde eu não teria um 'CONTROLE' natural eu poderia utilizar os CÓDIGOS para essas junções, seria isso? Por aí. A rigor, toda relação tem uma chave natural, amiúde composta. Em alguns casos, pode valer a pena definir uma chave artificial, que chamas de código; tem de ser uma avaliação caso a caso, e nunca pode substituir completamente a declaração da chave natural. Podemos dizer também que isso seria ideal não somente para PostgreSQL, mas para a modelagem mesmo de BD podendo aplicar para qualquer banco de dados relacional? Exato. Na verdade, não se pode falar em bases de dados relacional sem chave natural… porque sem chave natural, uma tabela não é uma relação, apenas um saco. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 13:39, Guimarães Faria Corcete DUTRA, Leandro escreveu: Eu digo um *monstrinho*, pois se eu tiver um login que é Email como PK, me parece que se tiver uns 4 ou 5 relacionamentos que você pode colocar no modelo (dependendo da solução), acho que pode começar a complicar as consultas, não? Pelo contrário, evita junções desnecessárias. Quase nunca evita. Pois, se eu tiver uma PK varchar(100) para Email OU uma PK inteiro (ou outro menor) para um código, *ACREDITO* que joins com código seja mais eficientes, não? Não, como o Euler e o Flávio explicaram… pelo contrário, quando precisares do endereço de correio eletrônico, o que é uma situação bem comum, com o uso de chaves artificiais como o teu código precisarás de junções para recuperá‐lo. O que acontece, é que num caso destes, normalmente você não quer o e-mail do usuário e sim o nome dele, ou a data de último login, ou a data de aniversário dele e a junção irá ocorrer da mesma forma. A não ser que faça sentido um relatório com a informação godinhaf...@gmail.com ou junior1...@gmail.com para identificar facilmente qual é o usuário que fez alguma coisa. Vejo como raríssimos os casos em que você não irá precisar de junção e nestes casos estão as entidades que tem uma chave natural óbvia como a UF da federação, tipo de pessoa: Física ou Jurídica, entre outros... -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Pelo contrário, evita junções desnecessárias. Quase nunca evita. Não é minha experiência, nem a de muitos outros. O que acontece, é que num caso destes, normalmente você não quer o e-mail do usuário e sim o nome dele, ou a data de último login, ou a data de aniversário dele e a junção irá ocorrer da mesma forma. Nalgumas situações sim, noutras não. Endereço de correio eletrônico é apenas um exemplo. Vejo como raríssimos os casos em que você não irá precisar de junção e nestes casos estão as entidades que tem uma chave natural óbvia como a UF da federação, tipo de pessoa: Física ou Jurídica, entre outros... Toda chave natural é óbvia se a análise foi bem feita. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 14:18, Guimarães Faria Corcete DUTRA, Leandro escreveu: Toda chave natural é óbvia se a análise foi bem feita. Vamos para o desafio de tentar achar uma chave natural para a entidade Cliente que será usada em um simples sistema de vendas novamente? Agente já viu aqui que isto não é tão óbvio, nem quando a análise é bem feita Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Na minha opinião, código de CLIENTE e número de PEDIDO são chaves naturais, mesmo que alguns pensem que são artificiais. Explico: desde o final do século retrasado, muito antes da invenção do computadores, comerciantes armazenavam fichas de papel com dados de seus clientes, geralmente em fichários. Muitas destas fichas tinham pré-impresso, pela gráfica, um número em um canto superior. Este número acabava virando o código do cliente. Da mesma forma, quase todos os talões de pedidos do século 19 já tinham um número impresso, via gráfica. O comerciante tirava o pedido este número entrava na operação. O cliente perguntava pelo pedido X, o comerciante sabia que pedido era. Até hoje, se você for numa loja que tira pedidos escritos à mão, verá que há sim um número impresso no papel. Em restaurantes isto é bem comum. Em 17 de fevereiro de 2012 14:43, Shander Lyrio shan...@nucleo45.com.brescreveu: Em 17/02/2012 14:18, Guimarães Faria Corcete DUTRA, Leandro escreveu: Toda chave natural é óbvia se a análise foi bem feita. Vamos para o desafio de tentar achar uma chave natural para a entidade Cliente que será usada em um simples sistema de vendas novamente? Agente já viu aqui que isto não é tão óbvio, nem quando a análise é bem feita -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 14:18, Guimarães Faria Corcete DUTRA, Leandro escreveu: O que acontece, é que num caso destes, normalmente você não quer o e-mail do usuário e sim o nome dele, ou a data de último login, ou a data de aniversário dele e a junção irá ocorrer da mesma forma. Nalgumas situações sim, noutras não. Endereço de correio eletrônico é apenas um exemplo. E você consegue então algum exemplo? sem ser de entidade com chaves naturais óbvias como Tipo Pessoa ou Estado? Vamos para o exemplo bem simples, imagine que conseguíssemos que toda pessoa física tivesse um RG e que esta informação fosse diferente par qualquer pessoa e nunca reutilizado. RG seria então um ótimo candidato a chave natural, isto seria um sonho. Você consegue pensar em algum tipo de relatório, em que seria importante ter o RG sem ter o nome da pessoa? São muito raros os casos, mas muito raros mesmo os que eu consigo pensar que não precise de junção. Portanto entendo que o argumento de necessitar de junção não vale para escolhas de chaves naturais ou artificiais, já que a não necessidade no caso das chaves naturais são exceção e não regra. -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Em 17/02/2012 14:18, Guimarães Faria Corcete DUTRA, Leandro escreveu: Toda chave natural é óbvia se a análise foi bem feita. Vamos para o desafio de tentar achar uma chave natural para a entidade Cliente que será usada em um simples sistema de vendas novamente? Agente já viu aqui que isto não é tão óbvio, nem quando a análise é bem feita Cadê os requisitos? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: Na minha opinião, código de CLIENTE e número de PEDIDO são chaves naturais, mesmo que alguns pensem que são artificiais. Podem ser, perfeitamente. Depende do caso. Se realmente a organização usa esses códigos ou números na comunicação humana ou homem‐máquina, eles deixam de ser artificiais e passam a ser naturais. A única complicação é que, geralmente, mesmo assim eles ainda correm o risco de não garantir unicidade. Mas não há problema nenhum em definir várias chaves… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: E você consegue então algum exemplo? sem ser de entidade com chaves naturais óbvias como Tipo Pessoa ou Estado? Como o colega havia colocado na mensagem original, login. Eu acrescentaria número de ponto, por exemplo; código do IBGE para localidades; códigos ISO para línguas, dialetos, territórios e subdivisões dos mesmos. Você consegue pensar em algum tipo de relatório, em que seria importante ter o RG sem ter o nome da pessoa? Sim, vários. Mas considero mais interessantes os casos com endereços de correio eletrônico, nomes de usuário, códigos ISO para línguas e territórios… São muito raros os casos, mas muito raros mesmo os que eu consigo pensar que não precise de junção. Portanto entendo que o argumento de necessitar de junção não vale para escolhas de chaves naturais ou artificiais, já que a não necessidade no caso das chaves naturais são exceção e não regra. Essa generalização é que, na minha experiência, é exagerada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
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
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Em 17/02/2012 15:06, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/2/17 Shander Lyrioshan...@nucleo45.com.br: Em 17/02/2012 14:18, Guimarães Faria Corcete DUTRA, Leandro escreveu: Vamos para o desafio de tentar achar uma chave natural para a entidade Cliente que será usada em um simples sistema de vendas novamente? Agente já viu aqui que isto não é tão óbvio, nem quando a análise é bem feita Cadê os requisitos? Vamos simplificar os requisitos para facilitar. Concessionária de carros que tem clientes que são pessoas físicas e jurídicas. Para facilitar é obrigatório o cadastramento de todos os dados dos clientes antes de executar uma venda. Cara, isso não existe — mas, se fosse simples assim, CPF/CNPJ seria (uma) chave natural. Mas imagino que a realidade, como sempre, seja bem mais complicada… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 15:13, Guimarães Faria Corcete DUTRA, Leandro escreveu: E você consegue então algum exemplo? sem ser de entidade com chaves naturais óbvias como Tipo Pessoa ou Estado? Como o colega havia colocado na mensagem original, login. Eu acrescentaria número de ponto, por exemplo; código do IBGE para localidades; códigos ISO para línguas, dialetos, territórios e subdivisões dos mesmos. Eu havia pedido sem ser chave naturais óbvias, ou seja, em todas estas com exeção do código do IBGE para localidades o próprio código já define facilmente a entidade. Você está forçando muito a barra achando que em algum relatório real, alguém vá colocar os códigos de localidades do IBGE ao invés do nome da localidade. Perceba que você está generalizando exageradamente para forçar seu ponto de vista. Essa generalização é que, na minha experiência, é exagerada. Do meu ponto de vista, quem está generalizando é você. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 15:56, Guimarães Faria Corcete DUTRA, Leandro escreveu: Vamos simplificar os requisitos para facilitar. Concessionária de carros que tem clientes que são pessoas físicas e jurídicas. Para facilitar é obrigatório o cadastramento de todos os dados dos clientes antes de executar uma venda. Cara, isso não existe — mas, se fosse simples assim, CPF/CNPJ seria (uma) chave natural. Mas imagino que a realidade, como sempre, seja bem mais complicada… Por isso que eu insisto que forçar a procura de chaves naturais para tudo é improdutivo. Olhe que nem tocamos no fato de o cliente poder ter uma micro empresa, neste caso ele teria um CPF e CNPJ mas seria a mesma pessoa. Eita Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 14:57, Alexsander Rosa escreveu: Na minha opinião, código de CLIENTE e número de PEDIDO são chaves naturais, mesmo que alguns pensem que são artificiais. Explico: desde o final do século retrasado, muito antes da invenção do computadores, comerciantes armazenavam fichas de papel com dados de seus clientes, geralmente em fichários. Muitas destas fichas tinham pré-impresso, pela gráfica, um número em um canto superior. Este número acabava virando o código do cliente. Da mesma forma, quase todos os talões de pedidos do século 19 já tinham um número impresso, via gráfica. O comerciante tirava o pedido este número entrava na operação. O cliente perguntava pelo pedido X, o comerciante sabia que pedido era. Até hoje, se você for numa loja que tira pedidos escritos à mão, verá que há sim um número impresso no papel. Em restaurantes isto é bem comum. A história é bonita, mas se você precisa adicionar uma informação a mais na entidade para identificá-la já chamamos de chave artificial não importa se já vem impressa no papel, chave natural é quando você usa um dos atributos da entidade para identificá-la. Concordo que Número de Pedido é chave Natural, mas não concordo com Código de Cliente. http://en.wikipedia.org/wiki/Natural_key -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 14:57, Alexsander Rosa escreveu: Na minha opinião, código de CLIENTE e número de PEDIDO são chaves naturais, mesmo que alguns pensem que são artificiais. Explico: desde o final do século retrasado, muito antes da invenção do computadores, comerciantes armazenavam fichas de papel com dados de seus clientes, geralmente em fichários. Muitas destas fichas tinham pré-impresso, pela gráfica, um número em um canto superior. Este número acabava virando o código do cliente. Isso não muda a definição, muitas destas não significam todas, logo não pode ser considerada chave natural. Uma chave natural identifica uma entidade em qualquer lugar, não apenas numa empresa específica. O João pode estar na ficha de número 10 no botequim do Araújo, mas na ficha 320 do Armazém do Tonhão. Este código não acompanha o João, não faz parte dele, não pode ser chave natural. Ele é um código criado na empresa para representar o João porque por acaso no momento do cadastro ele estava na folha 10, esta é exatamente a definição de chave artificial. O fato é que chaves artificiais não são do demônio e a boa prática pede que se evite tanto quanto possível as chaves artificiais, não que se extingua. É claro que isto deve ser feito com lógica e bom senso. O que estou defendendo é que é o fato de se usar chaves artificiais só torna o modelo opaco, porque a realidade do mundo real é efetivamente opaca e não tem como se fugir disto. Se a definição de chave artificial foi criada é exatamente porque é impossível modelar bancos de dados apenas com chaves naturais e a definição do Leandro ainda a pouco foi infeliz porque eu duvido que alguém o consiga, mesmo que seja bem modelado e tenha todo o tempo, recursos, etc etc... possíveis. -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Eu havia pedido sem ser chave naturais óbvias, ou seja, em todas estas com exeção do código do IBGE para localidades o próprio código já define facilmente a entidade. Mas esse é exatamente meu ponto: isso é muito comum. Você está forçando muito a barra achando que em algum relatório real, alguém vá colocar os códigos de localidades do IBGE ao invés do nome da localidade. Ah, desculpa, minha lembrança de dois anos e meio no Itaú deve ser forçada… brincando sério… De qualquer maneira, é um caso entre outros. Perceba que você está generalizando exageradamente para forçar seu ponto de vista. Desculpa, não consegui perceber isso. Essa generalização é que, na minha experiência, é exagerada. Do meu ponto de vista, quem está generalizando é você. E seguimos discordando… ninguém morrendo… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17 de fevereiro de 2012 15:07, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: Na minha opinião, código de CLIENTE e número de PEDIDO são chaves naturais, mesmo que alguns pensem que são artificiais. Podem ser, perfeitamente. Depende do caso. Se realmente a organização usa esses códigos ou números na comunicação humana ou homem‐máquina, eles deixam de ser artificiais e passam a ser naturais. A única complicação é que, geralmente, mesmo assim eles ainda correm o risco de não garantir unicidade. Mas não há problema nenhum em definir várias chaves… Nada impede que código do cliente e número do pedido sejam chaves naturais e primárias. No caso de pedido, nunca vi nem ouvi falar de um fabricante ou comerciante com um volume de negócios razoável que não use um número de pedido ou similar nas suas operações. Mesmo os mais antigos tinham talões de pedidos numerados pela gráfica. Não se trata de um número que não existia e foi criado pelo sistema, mas de um número que faz parte do comércio há séculos. Documento de 1901 com o número B 28821 impresso (EUA) http://www.flickr.com/photos/takeabreakwithme/3759289819/ Documento de 1920 com números impressos (EUA): http://www.flickr.com/photos/eggstudio/2123967684/ Documento de 1939 com número impresso ou carimbado (Itália) http://www.flickr.com/photos/takeabreakwithme/4005124923/ -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: Nada impede que código do cliente e número do pedido sejam chaves naturais e primárias. Claro, se realmente estão com o usuário! Eu só procuraria quais outras chaves naturais existem, no caso… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17/02/2012 16:28, Guimarães Faria Corcete DUTRA, Leandro escreveu: E seguimos discordando… ninguém morrendo… Faz parte! ;) -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
Em 17 de fevereiro de 2012 16:22, Shander Lyrio shan...@nucleo45.com.brescreveu: Em 17/02/2012 14:57, Alexsander Rosa escreveu: Da mesma forma, quase todos os talões de pedidos do século 19 já tinham um número impresso, via gráfica. O comerciante tirava o pedido este número entrava na operação. O cliente perguntava pelo pedido X, o comerciante sabia que pedido era. Até hoje, se você for numa loja que tira pedidos escritos à mão, verá que há sim um número impresso no papel. Em restaurantes isto é bem comum. A história é bonita, mas se você precisa adicionar uma informação a mais na entidade para identificá-la já chamamos de chave artificial não importa se já vem impressa no papel, chave natural é quando você usa um dos atributos da entidade para identificá-la. Mas se o número do pedido já vem impresso no papel, ele é sim um dos atributos da entidade. Por isso que surgiu o conceito de série: quando a gráfica esgotava os números (geralmente 5 ou 6 dígitos), criava uma nova série. Também já vi casos em que o ANO era impresso fixo no talão, formando um par ANO + NÚMERO que era usado como controle, os funcionários falavam em pedido X do ano Y. Veja que estou falando de talões de pedidos, em papel (geralmente com carbono), não de software. Concordo que Número de Pedido é chave Natural, mas não concordo com Código de Cliente. OK, concordamos com número de pedido. No caso de código de cliente, de fato, o uso de fichas numeradas mecanicamente não era tão comum quanto no caso dos pedidos. Muitos armazenavam as fichas pelo nome (às vezes com o sobrenome na frente), naqueles armários com gavetas A-Z. Até hoje muitos cartórios usam gavetas assim para armazenar as fichas de assinaturas. Para contornar o problema dos homônimos era preciso perguntar ao cliente o nome da mãe ou a data de nascimento, coisas assim. Um amigo meu passou por um problema por conta disto: ele tem um irmão gêmeo cujo nome é idêntico ao dele, mudando apenas uma letra. Ele nunca conseguiu tirar título de eleitor porque o sistema considerava que uma letra não era suficiente para diferenciar os dois, considerando que ele e o irmão tinham a mesma data de nascimento e o mesmo nome da mãe. O sistema rejeitava o cadastro por suspeita de fraude. Pelo que sei, até hoje ele não vota. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Fwd: Chave Primaria em VARCHAR
2012/2/17 Alexsander Rosa alexsander.r...@gmail.com: OK, concordamos com número de pedido. No caso de código de cliente, de fato, o uso de fichas numeradas mecanicamente não era tão comum quanto no caso dos pedidos. Mas o histórico é relevante? Na minha não tão humilde opinião, é interessantíssimo mas quase tão irrelevante quanto o papel em si. A questão é se o código, número ou seja‐lá‐o‐que‐fôr é necessário para a organização por causa de suas regras, métodos e requisitos, ou se é uma imposição do sistema informatizado; se for da organização, é uma chave natural a mais, e é, meio que por definição, boa; se for do sistema, é uma complicação a mais, uma chave artificial a ser evitada se possível. Um amigo meu passou por um problema por conta disto: ele tem um irmão gêmeo cujo nome é idêntico ao dele, mudando apenas uma letra. Ele nunca conseguiu tirar título de eleitor porque o sistema considerava que uma letra não era suficiente para diferenciar os dois, considerando que ele e o irmão tinham a mesma data de nascimento e o mesmo nome da mãe. O sistema rejeitava o cadastro por suspeita de fraude. Pelo que sei, até hoje ele não vota. Estranho o TSE não ter a competência do IBGE… e mostra os absurdos kafkianos da burocracia governamental! Acho que era do IBGE um caso de dois baianos nascidos no mesmo dia, na mesma cidade, com mesmos nome e sobrenome, e com nomes de pai e mãe idênticos. Não lembro qual foi a solução. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
