[pgbr-geral] Chave Primaria em VARCHAR
Bom dia pessoal! Estou modelando um sistema de autenticação de usuarios mas estou na duvida (Do ponto de vista do BD, e nao da aplicacao): a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? 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] Chave Primaria em VARCHAR
Moisés, bom dia, mas porque precisa ser login PK? Porque você não faz o basico: Criar um Codigo como PK e 'colocar' o Codigo no GRUPO? No meu ponto de vista tais preparando um *monstrinho*, caso não seja um TESTE SEU! Att, capin 2012/2/17 Moisés P. Sena moisesps...@gmail.com Bom dia pessoal! Estou modelando um sistema de autenticação de usuarios mas estou na duvida (Do ponto de vista do BD, e nao da aplicacao): a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? 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 -- 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] Chave Primaria em VARCHAR
Em 17 de fevereiro de 2012 09:57, Fernando Franquini 'capin' fernando.franqu...@gmail.com escreveu: Moisés, bom dia, mas porque precisa ser login PK? Porque você não faz o basico: Criar um Codigo como PK e 'colocar' o Codigo no GRUPO? No meu ponto de vista tais preparando um *monstrinho*, caso não seja um TESTE SEU! Att, capin Eu sempre uso um BIGSERIAL, mas estou querendo entender o porque da coisa. É também porque tive estudando BD NoSQL e eles utilizar TEXTO nas chaves e tal. Mas nao estou comparando um com outro? porque um *monstrinho* ? porque usar BIGINT ou NAO se o login é também um valor único?? 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] Chave Primaria em VARCHAR
Corrigindo texto: *Mas nao estou comparando um com outro. [ É UMA AFIRMAÇÂO, e NAO UMA PERGUNTA ]* --- 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] Chave Primaria em VARCHAR
Le 2012-F-17 09h50, Moisés P. Sena a écrit : a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? As diferenças não são relevantes. O que queres fazer é o ideal. -- 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
Re: [pgbr-geral] Chave Primaria em VARCHAR
Le 2012-F-17 09h57, Fernando Franquini 'capin' a écrit : bom dia, mas porque precisa ser login PK? Porque é o correto, sendo uma chave natural. Porque você não faz o basico: Criar um Codigo como PK e 'colocar' o Codigo no GRUPO? Porque está errado. Código engorda o modelo, o torna opaco, força junções desnecessária, suja cache e ocupa disco, gera E/S e, principalmente, não garante unicidade. No meu ponto de vista tais preparando um *monstrinho*, caso não seja um TESTE SEU! Por quê? -- 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
Re: [pgbr-geral] Max locks per transacition
Quando falo em OIDS, quero dizer que mantemos arquivos dentro do banco de dados, pode ser que eu esteja representando ou informando de forma errada, mas eh assim que chamamos os arquivos quando os importamos para dentro do PostgreSQL (lo_import) Desculpe, não tenho muita familiaridade sobre o uso do lo_import. O aumento desse parâmetro aumenta o tamanho da tabela de locks que ocupa uma parte da memória compartilhada (a.k.a shared_buffers). Então o aumento da tabela de locks simplismente faz com que eu passe a ocupar ou reservar um maoir espaço da memória usada no shared_buffers ? Sim, basicamente. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? As diferenças não são relevantes. O que queres fazer é o ideal. Li alguns testes de fora do Brasil recomendando usar char ao invés de varchar quando se necessita maior desempenho. Não sei se ainda se aplicam nas versões recentes do PostgreSQL. Fora isso, o impacto no desempenho em relação a números é irrelevante. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
2012/2/17 Euler Taveira de Oliveira eu...@timbira.com: Apostaria alguns centavos que o CHAR é um pouco mais lento do que o VARCHAR. Sério? Por quê, e seria relevante em que escala de operações? Se alguém puder nos refrescar a memória, tinha um artigo do Fetter a respeito, não? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Sério? Por quê, e seria relevante em que escala de operações? Se alguém puder nos refrescar a memória, tinha um artigo do Fetter a respeito, não? Euler já esclareceu. Nas versões recentes, não faz mais sentido algum. []s Flavio Gurgel ___ 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] Chave Primaria em VARCHAR
Em 17/02/2012 09:50, Moisés P. Sena escreveu: Bom dia pessoal! Estou modelando um sistema de autenticação de usuarios mas estou na duvida (Do ponto de vista do BD, e nao da aplicacao): a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? Acho que depende muito, tenho sistemas de controle de entregas e portanto uma tabela de tracking de cada uma destas entregas. Nesta tabela tenho informações de o que cada usuário que manuseou esta entrega fez. Em um cliente esta tabela tem mais de 2 bilhões de registros. Antes eu utilizava o código de barras das entregas como sendo minha chave primária e portanto, tipo varchar. Quando fiz testes com biginteger tive uma melhoria muito substancial de performance e de espaço em disco ocupado, além de índices muito menores. Eu quase sempre utilizo chaves artificiais. Porque conforme já expressei minha opinião aqui na lista, na prática, é quase impossível conseguir chaves naturais fiáveis. São poucas as entidades que o possuem. Cada um sabe onde seu sapato aperta. Levando para seu exemplo, tente imaginar, que nesta tabela de tracking eu armazeno o usuário e ao invés de gravar o código deste usuário (integer), 123 por exemplo, eu gravasse o nome: EDMILSON.NASCIMENTO. Só com este campo desta tabela eu teria cerca de 27 GB de espaço economizado, sem contar os índices. Por mais que tentem me convencer que a diferença de performance não é grande, para mim é suficientemente grande. 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] Chave Primaria em VARCHAR
Em 17/02/2012 09:50, Moisés P. Sena escreveu: Bom dia pessoal! Estou modelando um sistema de autenticação de usuarios mas estou na duvida (Do ponto de vista do BD, e nao da aplicacao): a) Quero colocar o login como PK da tabela usuario como VARCHAR(30) b) Quero colocar o nome como PK da tabela grupo como VARCHAR(30) O que voces me falam de performance em usar VARCHAR ou BIGINT? Existe algum outro campo de texto mais rapido que VARCHAR? Acho que depende muito, tenho sistemas de controle de entregas e portanto uma tabela de tracking de cada uma destas entregas. Nesta tabela tenho informações de o que cada usuário que manuseou esta entrega fez. Em um cliente esta tabela tem mais de 2 bilhões de registros. Antes eu utilizava o código de barras das entregas como sendo minha chave primária e portanto, tipo varchar. Quando fiz testes com biginteger tive uma melhoria muito substancial de performance e de espaço em disco ocupado, além de índices muito menores. Eu quase sempre utilizo chaves artificiais. Porque conforme já expressei minha opinião aqui na lista, na prática, é quase impossível conseguir chaves naturais fiáveis. São poucas as entidades que o possuem. Cada um sabe onde seu sapato aperta. Levando para seu exemplo, tente imaginar, que nesta tabela de tracking eu armazeno o usuário e ao invés de gravar o código deste usuário (integer), 123 por exemplo, eu gravasse o nome: EDMILSON.NASCIMENTO. Só com este campo desta tabela eu teria cerca de 27 GB de espaço economizado, sem contar os índices. Por mais que tentem me convencer que a diferença de performance não é grande, para mim é suficientemente grande. 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
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] Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Em um cliente esta tabela tem mais de 2 bilhões de registros. Antes eu utilizava o código de barras das entregas como sendo minha chave primária e portanto, tipo varchar. Quando fiz testes com biginteger tive uma melhoria muito substancial de performance e de espaço em disco ocupado, além de índices muito menores. Teu caso nem discuto, como já disse antes há situações onde as limitações tecnológicas dos sistemas SQL, e até do SQL em si, nos forçam a expor as chaves artificiais. Mas não são o caso geral. Já disse antes, mas repito: os casos em que é razoável considerar o caso de usar chaves artificiais são massas de dados muito grandes, e chaves exportadas como estrangeiras a tabelas filhas bem maiores que as tabelas mães. Parece que teu caso está nas duas categorias. Mesmo assim, eu tentaria avaliar os ganhos óbvios de espaço face aos não tão óbvios custos de junções. Eu quase sempre utilizo chaves artificiais. Porque conforme já expressei minha opinião aqui na lista, na prática, é quase impossível conseguir chaves naturais fiáveis. São poucas as entidades que o possuem. Aí é que discordo, e nunca ninguém mostrou aqui. Pelo contrário, se não há chave natural, não é entidade ou não está bem analisada. Dá para fazer funcionar, mas longe do melhor. Cada um sabe onde seu sapato aperta. Exato. Amiúde, é até falta de condições — tempo, recursos, informações, conhecimento, confiança, um SGBD decente — de fazer uma análise e implementação decentes. ___ 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] Chave Primaria em VARCHAR
On 17-02-2012 12:10, Guimarães Faria Corcete DUTRA, Leandro wrote: 2012/2/17 Euler Taveira de Oliveira eu...@timbira.com: Apostaria alguns centavos que o CHAR é um pouco mais lento do que o VARCHAR. Sério? Por quê, e seria relevante em que escala de operações? Naquelas operações cuja cadeia de caracteres armazenadas é menor do que n (em CHAR(n)). Isso por conta de ter que fazer o preenchimento com espaços. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Em 17/02/2012 14:13, Guimarães Faria Corcete DUTRA, Leandro escreveu: Eu quase sempre utilizo chaves artificiais. Porque conforme já expressei minha opinião aqui na lista, na prática, é quase impossível conseguir chaves naturais fiáveis. São poucas as entidades que o possuem. Aí é que discordo, e nunca ninguém mostrou aqui. Pelo contrário, se não há chave natural, não é entidade ou não está bem analisada. Dá para fazer funcionar, mas longe do melhor. Até onde estudei sobre bancos de dados, para ser considerada uma entidade precisamos ter uma chave que o identifique, seja natural ou artificial. Natural quando o atributo faz parte do objeto modelado e artificial quando não. Isto é bonito filosoficamente, já discutimos sobre isto e você não conseguiu me dar uma chave natural fiável para um Cliente que é uma entidade super comum. Quem conseguiria analisar ela bem? Ela não é uma entidade? Se tem uma chave única, natural ou não, ela é uma entidade, sua afirmação, por mais categórica que seja, não consegue mudar este fato. A boa prática indica que devemos sempre dar preferencia aos atributos naturais para evitar a repetição. Esta discussão sempre me faz lembrar das aulas de filosofia na Faculdade. Para um sistema especialista, com regras criteriosamente definidas dentro de uma empresa, e que somente rode para esta empresa, sua abordagem até faz sentido. Mas este mundo ideal não passa daí. Quem desenvolve sistemas para vários clientes, com regras diferentes percebe rapidamente, que ser generalista resolve os problemas mais facilmente e sem dor, um índice unique é muito mais simples para garantir unicidade de que convencer o cliente que ele tem que cadastrar diversas informações que não serão usadas no negócio dele só para que o modelo de dados fique bonitinho e para que a lista de postgresql não o ache opaco e sem graça. Cada um sabe onde seu sapato aperta. Exato. Amiúde, é até falta de condições — tempo, recursos, informações, conhecimento, confiança, um SGBD decente — de fazer uma análise e implementação decentes. Ou não, acho que apenas o tipo de nicho de sistemas serviria para diferenciar, sistema que só roda em um único cliente com regras muito bem definidas ou mais de um com regras bem definidas e compartilhadas, e sistemas que rodam em vários clientes com regras muito diversificadas. No geral, são muito mais raros os sistemas feitos para rodar em apenas um cliente. 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: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] Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Até onde estudei sobre bancos de dados, para ser considerada uma entidade precisamos ter uma chave que o identifique, seja natural ou artificial. Não, a artificial, como diz o nome, é apenas um artifício físico, que por limitações do SQL aparece para o usuário. Idealmente, somente o DBA a veria. Ela não identifica a tupla (lógica), tanto que não garante unicidade; apenas identifica o registro (físico). Sem identificação, não é entidade, nem relação. Natural quando o atributo faz parte do objeto modelado e artificial quando não. Isto é bonito filosoficamente, já discutimos sobre isto e você não conseguiu me dar uma chave natural fiável para um Cliente que é uma entidade super comum. Quem conseguiria analisar ela bem? Ela não é uma entidade? Consegui, como não? Mas não existe solução genérica, é sempre conforme os requisitos e regras organizacionais (vulgo ‘de negócios’). Quem desenvolve sistemas para vários clientes, com regras diferentes percebe rapidamente, que ser generalista resolve os problemas mais facilmente e sem dor, um índice unique é muito mais simples para garantir unicidade Só que não garante unicidade… e tenho cabelos brancos por isso… é simples: sem chave natural, é só ir inserindo as mesmas informações, vez após vez, e pronto. Cadê a unicidade? Se, por acaso, o sistema confere algo para evitar essa multiplicação de dados, esse algo é a chave natural… de que convencer o cliente que ele tem que cadastrar diversas informações que não serão usadas no negócio dele Aí o problema é um modelo genérico para um cliente com necessidades específicas. Pode ser que não valha a pena atender suas necessidades, mas essa é uma decisão de negócio de correr os riscos de negócio decorrentes da modelagem inespecífica. No geral, são muito mais raros os sistemas feitos para rodar em apenas um cliente. Na tua experiência, acredito… ___ 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] Chave Primaria em VARCHAR
Em 17/02/2012 15:05, Guimarães Faria Corcete DUTRA, Leandro escreveu: Consegui, como não? Mas não existe solução genérica, é sempre conforme os requisitos e regras organizacionais (vulgo ‘de negócios’). Conseguiu, eu não me lembro disso não, pode me refrescar a memória? Qual atributo usou? Depende da empresa né? Você sugere então que tenhamos um modelo de banco de dados para cada empresa. Este mundo fantástico não existe. Quem desenvolve sistemas para vários clientes, com regras diferentes percebe rapidamente, que ser generalista resolve os problemas mais facilmente e sem dor, um índice unique é muito mais simples para garantir unicidade Só que não garante unicidade… e tenho cabelos brancos por isso… é simples: sem chave natural, é só ir inserindo as mesmas informações, vez após vez, e pronto. Cadê a unicidade? Se, por acaso, o sistema confere algo para evitar essa multiplicação de dados, esse algo é a chave natural… Como é que é?? Um índice unique não garante unidade?? Para que ele existe então? No banco de dados, uma chave primária tem garantia de unicidade exatamente pelo índice unique que é gerado. O fato é que o modelo genérico que eu proponho, resolve o problema para qualquer tipo de cliente. Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo, isto é uma simples decisão de engenharia, custo/benefício da solução. Da sua forma, o cliente é obrigado a fazer caso contrário o sistema não funciona. No geral, são muito mais raros os sistemas feitos para rodar em apenas um cliente. Na tua experiência, acredito… Fora quando a empresa desenvolve seu próprio sistema (exceção), os sistemas são feitos geralmente para rodar em vários clientes. Exemplos? SAP? Oracle? postgresql? Inúmeros ERP's e CRM's. Conta-se nos dedos os sistemas feitos para uma única empresa, então impor sua realidade num mundo que não é assim tão perfeito quando você sonha não ajuda. Seria muito legal se cada cliente tivesse o seu sistema específico, com seu banco de dados modelados de acordo com suas regras (a maioria nem tem estas regras), eu teria serviço de DBA para o resto da minha vida. -- 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] Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Conseguiu, eu não me lembro disso não, pode me refrescar a memória? Qual atributo usou? Depende da empresa né? Você sugere então que tenhamos um modelo de banco de dados para cada empresa. Este mundo fantástico não existe. Uai, devo ser um fantasma então… Como é que é?? Um índice unique não garante unidade?? Para que ele existe então? Tentarei evitar me repetir, então só direi que, ao reler minhas mensagens anteriores, tem‐se de entender a distinção entre modelos lógico (chave) e físico (índice) — infelizmente, o SQL não diferencia isso claramente. Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo Isso eu não entendi… isto é uma simples decisão de engenharia, custo/benefício da solução. Claro! Fora quando a empresa desenvolve seu próprio sistema (exceção), os sistemas são feitos geralmente para rodar em vários clientes. Exemplos? SAP? Oracle? postgresql? Inúmeros ERP's e CRM's. Conta-se nos dedos os sistemas feitos para uma única empresa, então impor sua realidade num mundo que não é assim tão perfeito quando você sonha não ajuda. Sistemas genéricos há aos montes, e há aos montes personalizações, e sistemas específicos. Seria muito legal se cada cliente tivesse o seu sistema específico, com seu banco de dados modelados de acordo com suas regras (a maioria nem tem estas regras), eu teria serviço de DBA para o resto da minha vida. Como eu disse, é a tentação dos geradores de código. ___ 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] Chave Primaria em VARCHAR
Em 17/02/2012 15:55, Guimarães Faria Corcete DUTRA, Leandro escreveu: Uai, devo ser um fantasma então… Não que seja fantasma, mas que vive num mundo muito especial e perfeito. lógico (chave) e físico (índice) — infelizmente, o SQL não diferencia isso claramente. Se estamos falando de postgresql, que usa o sql, porque não detém suas respostas a este mundo falível? Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo Isso eu não entendi… No seu mundo perfeito onde todos os clientes tenham um documento único padrão que não se repete e que o acompanha para o resto da vida, você pode usar este atributo como chave primária natural, seu sistema garante unicidade para casos de CPF repetidos e portanto barra clientes repetidos. No meu mundo imperfeito os clientes tem o CPF mas podem ter esquecido em casa, e não saber de cor, nem por isto eu quero perder a venda, então o meu cliente, pode deixar de vender para deixar o banco de dados fofo e cuti cuti, ou vender, e correr o risco de ter um cliente duplicado no sistema. Se o cliente trouxer o CPF e eu for cadastrá-lo, o índice unique neste campo garante a mesma unicidade que no seu modelo perfeito, mas permite que o meu cliente escolha o que é melhor par ele, duplicar ou não duplicar, cadastrar ou não o cpf. 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] Chave Primaria em VARCHAR
Em 17 de fevereiro de 2012 15:55, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo Isso eu não entendi… Sério, como é que você consegue só avisar que o dado esta sendo duplicado com um Index Unique? O que vejo, é que o Leandro utiliza chaves primárias para criar suas chaves naturais e o Shander não cria chaves primarias ou invés cria indices únicos para alguns campos que ele julga necessário. Ou será que você deixa tudo por conta da aplicação? ___ 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] Chave Primaria em VARCHAR
2012/2/17 Flávio Alves Granato flavio.gran...@gmail.com: Em 17 de fevereiro de 2012 15:55, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo Isso eu não entendi… Sério, como é que você consegue só avisar que o dado esta sendo duplicado com um Index Unique? Acho que ou não entendemos, ou não foi bem explicado… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Em 17/02/2012 16:42, Flávio Alves Granato escreveu: Em 17 de fevereiro de 2012 15:55, Guimarães Faria Corcete DUTRA, Leandrol...@dutras.org escreveu: 2012/2/17 Shander Lyrioshan...@nucleo45.com.br: Se ele cadastra o campo em que eu tenho um índice unique o sistema avisa da duplicidade, se não não avisa, o risco fica por conta do cliente sem que eu o obrigue a fazê-lo Isso eu não entendi… Sério, como é que você consegue só avisar que o dado esta sendo duplicado com um Index Unique? Minha chave primária de tabela clientes é artificial. É um codigo_cliente do tipo integer. Vários outros atributos estão nesta tabela, incluindo cpf, cnpj, estes últimos com índices unique. Se você tentar inserir um cliente com cpf já cadastrado no sistema ele informará erro da mesma forma que seria informado se você tentasse incluir um cliente duplicado se o cpf fosse chave primária. Mas, como não utilizo o cpf como chave primária, e apenas crio uma restrição de unicidade, eu permito ao meu cliente que não utilize este campo se não quiser. No geral, eu não utilizo chaves naturais como chaves primárias, simplesmente porque não sou eu quem as controla nem controlo a regra de negócio que a forma. Claro que para as chaves naturais triviais como as citadas anteriormente, eu as utilizo, mas apenas nestes casos. Por exemplo, vamos supor que você utilize o login como chave primária, como foi sugerido anteriormente nesta thread. Um belo dia, o gerente Sem Noção da Silva, resolve que seria ótimo admitir logins repetidos para o caso de filiais diferentes da sua empresa, e que isto seria selecionado na tela inicial do sistema. Se você utiliza o login como chave primária, bem vindo ao inferno! Caso faça da forma com que eu estou propondo, mude o índice unique de login para codigo_filial + login e está resolvido o seu problema. Estas chaves normalmente se espalham pelo banco de dados inteiro, então eu prefiro ter certeza que a regra de negócio que as gera está sob o meu controle. 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 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] Chave Primaria em VARCHAR
Em 17/02/2012 16:42, Flávio Alves Granato escreveu: O que vejo, é que o Leandro utiliza chaves primárias para criar suas chaves naturais e o Shander não cria chaves primarias ou invés cria indices únicos para alguns campos que ele julga necessário. Ou será que você deixa tudo por conta da aplicação? E o que eu vejo é que você está subestimando muito meus conhecimentos e minha experiência com Bancos de Dados. -- 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] Chave Primaria em VARCHAR
Em 17/02/2012 17:43, Shander Lyrio escreveu: Em 17/02/2012 16:42, Flávio Alves Granato escreveu: O que vejo, é que o Leandro utiliza chaves primárias para criar suas chaves naturais e o Shander não cria chaves primarias ou invés cria indices únicos para alguns campos que ele julga necessário. Ou será que você deixa tudo por conta da aplicação? E o que eu vejo é que você está subestimando muito meus conhecimentos e minha experiência com Bancos de Dados. Ainda acho que você não é o centro do universo, me desculpe por esta heresia. Assim como discordo com o Leandro discordo de você. Se é difícil responder uma pergunta, eu sei que é muito mais fácil deixar de começar um flame... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Em 17/02/2012 18:00, Flávio Alves Granato escreveu: Ainda acho que você não é o centro do universo, me desculpe por esta heresia. Assim como discordo com o Leandro discordo de você. Se é difícil responder uma pergunta, eu sei que é muito mais fácil deixar de começar um flame... A pergunta foi respondida antes. Esta parte do seu e-mail recebeu uma resposta separada, em segundo momento. Engraçado perceber que você preferiu responder esta em detrimento à aquela. Não parece ser tão mais fácil deixar de começar um flame, certo? Vamos deixar este galho morrer e voltar para os argumentos. 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 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] Chave Primaria em VARCHAR
Em 17/02/2012 18:14, Shander Lyrio escreveu: Em 17/02/2012 18:00, Flávio Alves Granato escreveu: Ainda acho que você não é o centro do universo, me desculpe por esta heresia. Assim como discordo com o Leandro discordo de você. Se é difícil responder uma pergunta, eu sei que é muito mais fácil deixar de começar um flame... A pergunta foi respondida antes. Esta parte do seu e-mail recebeu uma resposta separada, em segundo momento. Engraçado perceber que você preferiu responder esta em detrimento à aquela. Não parece ser tão mais fácil deixar de começar um flame, certo? Pelo outro email ter respondido minha pergunta, continuo achando que não deveria responder. Agora, esta última resposta sua, falando do seu conhecimento, acho ainda que não era necessário. Qual motivo eu teria para dúvidar do conhecimento de alguém? Agora, você ainda acha isso, me parece muito mais um problema seu que meu. Vamos deixar este galho morrer e voltar para os argumentos. Apesar de não concordar com seus argumentos e preferi não dizer em resposta à sua primeira resposta, aceito seus argumentos. Pois, me soa muito como gambiarra do que com modelagem. A justificativa disso é, vamos fazer o que o cliente pede já que é ele que me paga, esqueça todo o resto, ( estou generalizando em todo o resto ). E quando isso ocorre, em futuros próximos a este ocorrido, normalmente tem que se dar muita volta para fazer pouca coisa... Não precisa responder, deixe a thread morrer. ___ 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
Re: [pgbr-geral] Chave Primaria em VARCHAR
2012/2/17 Shander Lyrio shan...@nucleo45.com.br: Modelar é oque? procurar chave natural que não existe ou Não existe inexistência de chave natural. quando existe escolher uma que provavelmente vai te dar dor de cabeça daqui a pouco? Chave natural é analgésico, não cefaléia. Se é possível fazer o que o cliente pede sem dor, porque eu iria preferir não fazer? Minha experiência com informação incompleta é que ela sempre volta para te pegar como assombração à meia noite, no melhor do melhor dos sonhos… Fato é que da forma que vocês propõem, se o documento único que o governo está propondo vingar, quem tem identidade como chave primária de suas aplicações vai ter um grande problema Não vejo como. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Fato é que da forma que vocês propõem, se o documento único que o governo está propondo vingar, quem tem identidade como chave primária de suas aplicações vai ter um grande problema Senhores, o Cadastro Único que gerou vários spams quando surgiu quando Lula era presidente (e foi apelidado nos spams de CU) na verdade se chama CadUnico (provavelmente pra evitar a sigla maldita) e não tem nada a ver com recadastrar todos os brasileiros. Ele é direcionado ao apoio do Bolsa Família e cadastro das famílias abaixo da linha de pobreza: http://www1.caixa.gov.br/gov/gov_social/municipal/distribuicao_servicos_cidadao/cadastramento_unico/index.asp Por enquanto, a melhor chave natural para brasileiros e estrangeiros legalizados é o CPF (embora tenha seus problemas). Até crianças pequenas tem CPF se os pais decidirem, por exemplo, abrir uma poupança, o que tive de fazer com meu filho. Outros exemplos de chaves naturais seriam código de um cartório, livro e folha do registro de nascidos vivos. Complicado, né? Alguém já decorou o seu? Ih, quando casamos, passa a ser o código do cartótio, livro, folha do registro de estado civil e sexo do cônjuge (pra separar naturalmente os membros de um casa). Aí ferrou de vez... pode piorar quando a união homoafetiva for registrada dessa forma, aí, não terá como, teríamos uma chave artificial já no cartório: o integrante número 1 e o de número 2 da família. Exemplos de outras chaves naturais para seres humanos: - alguma forma de representar em código a impressão digital; - idéia similar para o fundo do olho; - sequência de DNA. Em alguns países como a França, o equivalente ao RG brasileiro, por exemplo, não é obrigatório. Acho que esta thread é um recorde de postagens nesta lista. Pelo menos recorde num único dia. Mais de 50 mensagens! []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria em VARCHAR
Le 2012-F-17 22h14, Flavio Henrique Araque Gurgel a écrit : Em alguns países como a França, o equivalente ao RG brasileiro, por exemplo, não é obrigatório Claro, a França não foi ditadura. Isso é resquício da ditadura Vargas, para controlar os dissidentes, quando não eram exilados ou assassinados de vez. -- 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
