Re: [pgbr-geral] Tipos de dados

[Gerdan Rezende dos Santos]

Em segunda-feira, 23 de novembro de 2015, Sebastian Webber <
sebast...@swebber.me> escreveu:

>
>
> Em 23 de novembro de 2015 19:32, Dickson S. Guedes  > escreveu:
>
>> Em 21 de novembro de 2015 18:14, Flavio Henrique Araque Gurgel
>> >
>> escreveu:
>> >
>> > http://pgxn.org/dist/validadores/
>>
>> Esta extensão é antiga, criei ela no PGBR 2011 como demonstração e no
>> PGDay PR publiquei a mesma na PGXN em caráter de demonstração também.
>> Mas estamos em 2015 então criei vergonha na cara e coloquei o projeto
>> no Github [1] para quem quiser contribuir. :D
>>
>> [1] https://github.com/guedes/validadores
>
>
> Quem sabe a gente não faz um esforço e já implementamos os caras que
> faltam? E quero dizer CNPJ, titulo eleitor, telefone, etc e etc.
>
> Eu já comecei a implementar o CNPJ[1]. Aproveitei a função pronta do
> euler[2] e as mascaras que foram criadas nos links que mandei.
>
> Partiu?
>
> [1] https://github.com/guedes/validadores/pull/1
> [2] https://wiki.postgresql.org/wiki/CNPJ
>
>
>
>
>
>
>
> --
> Sebastian Webber
> http://swebber.me
>



Partiu pego CEP! Euler que me ajude... Rsrsrs


-- 
T.'.A.'.F.'.,
*Gerdan Rezende dos Santos *
*Po*stgreSQL & EnterpriseDB Specialist, Support, Training & Services
+55 (61) 9645-1525
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Osvaldo Kussama]

Em 23/11/15, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> 2015-11-23 15:58 GMT-02:00 Sebastian Webber :
>>
>> Meu caro Dutra, segundo a doc[1], dá pra dizer que:
>>
>> CREATE DOMAIN creates a new domain. A domain is essentially a data type
>> with
>> optional constraints (restrictions on the allowed set of values) ...
>
> Então, mais ou menos… esse é um ponto em que nossa documentação comete
> um erro conceitual grosseiro.
>
>
>> Domains are useful for abstracting common constraints on fields into a
>> single location for maintenance.
>
> Perfeito, mas não apenas.
>
> O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade.
> Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus
> assuntos favoritos, tentarei de novo:
>
> Um domínio é uma lista de valores — conceitualmente, porque podem ser
> valores contínuos (não discretos), caso em que a lista não pode ser
> realizada; idem para domínios infinitos.  Um tipo de dados é um
> domínio e seus operadores.
>
> Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um
> número de até onze caracteres, ou precisamente onze se o precedermos
> de zeros.  Até onde eu saiba; perdoem alguma imprecisão no exemplo.  O
> domínio CPF é constituído de todos os números de CPF válidos.  Como
> apenas os nove números excluindo os dois dígitos verificadores à
> direita são relevantes para gerar a lista, podemos dizer que o
> domínio, a princípio, seria de 1 a 999.999.999, concatenados com os
> respectivos dígitos verificadores.  No caso, suponho que 0 seja um
> caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs
> correspondentes a 0.
>
> Já o tipo de dados seriam os operadores correspondentes.  Não consigo
> imaginar, de bate-pronto, algum operador que não seja o de identidade
> (comparação para ver se é igual ou diferente); por exemplo, não me
> parece fazer sentido querer concatenar, cortar, somar, subtrair,
> multiplicar, dividir, comparar se maior ou menos   Talvez
> operadores para extrair os dígitos significativos (os nove excetuando
> os DVs) e os dígitos verificadores.
>
> O interessante a reter é que não faz sentido operar num determinado
> domínio com operadores que não correspondam ao tipo.  Portanto, por
> definição, uma definição de domínio tem de excluir operações de outros
> tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam
> outros domínios sem que sejam operações especificamente previstas para
> o domínio em questão e outro domínio qualuqer (por exemplo, concatenar
> um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ).
>
> Até onde já li e testei, um DOMAIN SQL não impede isso.  Teste; deve
> ser possível CREATE TABLE cpf (cpf AS cpf);  com esse DOMAIN, e fazer
> um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio
> de verdade.
>
> Aproveitando para bater noutra tecla que me é cara, é por causa desse
> tipo de problema de confusão conceitual (embora não desse problema
> específico) que o SQL não é relacional: para começo de conversa, uma
> tabela SQL não necessariamente é uma relação (que precisa de ao menos
> uma chave natural), mas pode ser um saco (sem chave natural, ou seja,
> não é um conjunto).
>
>
>> For example, several tables might contain
>> email address columns, all requiring the same CHECK constraint to verify
>> the
>> address syntax. Define a domain rather than setting up each table's
>> constraint individually.
>
> Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar
> uma restrição de validação.
>
>
>> Chamamos isso de empate técnico? :D
>>
>> [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm
>
> Posso dizer que não é uma disputa, portanto não faz sentido falar em
> empate?  ;-)
>
>

Olá Dutra:

Não sei se existe CPF 0-XX mas o CNPJ do Banco de Brasil é:
00.000.000/0001-91

Que, pelas suas considerações, seria um domínio de 0 a 
acrescido da filial, de 0001 a , e dos DV.

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 17:24 GMT-02:00 Osvaldo Kussama :
> Não sei se existe CPF 0-XX mas o CNPJ do Banco de Brasil é:
> 00.000.000/0001-91

Boa!  ;-)


> Que, pelas suas considerações, seria um domínio de 0 a 
> acrescido da filial, de 0001 a , e dos DV.

Exato.  Mais uma vez, imagino que não haja CNPJ 00.000.000/, ou filiais /.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 15:58 GMT-02:00 Sebastian Webber :
>
> Meu caro Dutra, segundo a doc[1], dá pra dizer que:
>
> CREATE DOMAIN creates a new domain. A domain is essentially a data type with
> optional constraints (restrictions on the allowed set of values) ...

Então, mais ou menos… esse é um ponto em que nossa documentação comete
um erro conceitual grosseiro.


> Domains are useful for abstracting common constraints on fields into a
> single location for maintenance.

Perfeito, mas não apenas.

O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade.
Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus
assuntos favoritos, tentarei de novo:

Um domínio é uma lista de valores — conceitualmente, porque podem ser
valores contínuos (não discretos), caso em que a lista não pode ser
realizada; idem para domínios infinitos.  Um tipo de dados é um
domínio e seus operadores.

Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um
número de até onze caracteres, ou precisamente onze se o precedermos
de zeros.  Até onde eu saiba; perdoem alguma imprecisão no exemplo.  O
domínio CPF é constituído de todos os números de CPF válidos.  Como
apenas os nove números excluindo os dois dígitos verificadores à
direita são relevantes para gerar a lista, podemos dizer que o
domínio, a princípio, seria de 1 a 999.999.999, concatenados com os
respectivos dígitos verificadores.  No caso, suponho que 0 seja um
caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs
correspondentes a 0.

Já o tipo de dados seriam os operadores correspondentes.  Não consigo
imaginar, de bate-pronto, algum operador que não seja o de identidade
(comparação para ver se é igual ou diferente); por exemplo, não me
parece fazer sentido querer concatenar, cortar, somar, subtrair,
multiplicar, dividir, comparar se maior ou menos   Talvez
operadores para extrair os dígitos significativos (os nove excetuando
os DVs) e os dígitos verificadores.

O interessante a reter é que não faz sentido operar num determinado
domínio com operadores que não correspondam ao tipo.  Portanto, por
definição, uma definição de domínio tem de excluir operações de outros
tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam
outros domínios sem que sejam operações especificamente previstas para
o domínio em questão e outro domínio qualuqer (por exemplo, concatenar
um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ).

Até onde já li e testei, um DOMAIN SQL não impede isso.  Teste; deve
ser possível CREATE TABLE cpf (cpf AS cpf);  com esse DOMAIN, e fazer
um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio
de verdade.

Aproveitando para bater noutra tecla que me é cara, é por causa desse
tipo de problema de confusão conceitual (embora não desse problema
específico) que o SQL não é relacional: para começo de conversa, uma
tabela SQL não necessariamente é uma relação (que precisa de ao menos
uma chave natural), mas pode ser um saco (sem chave natural, ou seja,
não é um conjunto).


> For example, several tables might contain
> email address columns, all requiring the same CHECK constraint to verify the
> address syntax. Define a domain rather than setting up each table's
> constraint individually.

Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar
uma restrição de validação.


> Chamamos isso de empate técnico? :D
>
> [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm

Posso dizer que não é uma disputa, portanto não faz sentido falar em
empate?  ;-)


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] Tipos de dados

[Fernando Cambiaghi]

>
> Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns
> testes com o teu volume de dados e avalie qual deles tem um melhor
> desempenho. Creio eu que comparação de números tende a ser mais eficiente
> que strings. Teste e voltamos a conversar, ok?
>
>
> Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto
de vocês, mas gostaria de deixar minha consideração.
Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e
não tenho ideia do trabalho que daria para alterar, mas fiz uns testes
baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está
o resultado:

select 'bigint', pg_size_pretty( sum(pg_column_size( 99::bigint
)) )
union
select 'char_14', pg_size_pretty( sum(pg_column_size(
'99'::char(14) )) )
union
select 'char_20', pg_size_pretty( sum(pg_column_size(
'99'::char(20) )) );

char_14  : 18 bytes
char_20  : 24 bytes
bigint  :  8 bytes

Achei interessante, e vai de encontro a resposta do Sebastian quanto a usar
numéricos.

Att,
Fernando Luís Cambiaghi.
(Analista de Sistemas Sênior)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-23 14:26 GMT-02:00 Sebastian Webber :
>
> Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de
> validações feito pelo guedes ele já implementa o tipo de dados cpf. e com
> isso já facilita a validação do mesmo como numeric.

Sendo um pouco chato, mas no interesse da precisão, até onde entendi o
módulo — muito útil — implementa um DOMAIN SQL, o que não é um domínio
(!), portanto não é um tipo de dado; mas é a coisa mais parecida, e
útil, com um domínio de verdade.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-22 22:47 GMT-02:00 Gerdan Rezende dos Santos :
> Cpf com zero?? O meu comeca assim 001... Te respondi???

Não.  Perguntei ‘que têm’, quer dizer, que diferença faz (dado tudo
que já conversamos até aqui).


> Transformação no banco custa, banco e pra armazanar e consultar

Armazenamento e consulta também custam.  A avaliar o que custa mais.
E outra: geralmente o gargalo num sistema é E/S, não processamento.
Portanto, geralmente vale a pena economizar armazenamento se o custo
em processamento não for exagerado.  E não parece ser.


> quer deixar bonito bota na aplicacao

A aplicação pode estar na base de dados também.  Aliás, é o melhor
lugar para ficar, garantindo consistência em qualquer uso, por
qualquer programa aplicativo, e compartilhando recursos com o resto do
servidor.


> se a mascara for executada no cliente melhor ainda...

Pior.  Quanto mais perto dos dados, melhor, tanto em velocidade
(latência, compartilhamento de recursos) quanto em consistência.


> Pq usar char?? Poderia comecar te dizendo pra ser ter um padrão no seu
> armazanamento...

Um padrão qualquer é melhor que padrão nenhum.  Mas um padrão
específico não é obviamente mais útil em si mesmo que um padrão
alternativo, sem alguma explicação.


> Ah qto a você me sacanear...

Não sacaneei nada.  Só achei que você seria capaz de contribuir ainda mais.


> Sua preoculpação deveria ser em ajudar ao colega

E foi.


> eu não sou dono da verdade!

Mas escreveu como se achasse ser.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] Tipos de dados

[Sebastian Webber]

Em 23 de novembro de 2015 15:13, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2015-11-23 14:26 GMT-02:00 Sebastian Webber :
> >
> > Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de
> > validações feito pelo guedes ele já implementa o tipo de dados cpf. e com
> > isso já facilita a validação do mesmo como numeric.
>
> Sendo um pouco chato, mas no interesse da precisão, até onde entendi o
> módulo — muito útil — implementa um DOMAIN SQL, o que não é um domínio
> (!), portanto não é um tipo de dado; mas é a coisa mais parecida, e
> útil, com um domínio de verdade.


Meu caro Dutra, segundo a doc[1], dá pra dizer que:

CREATE DOMAIN creates a new domain. A domain is essentially a data type
with optional constraints (restrictions on the allowed set of values) ...
...
Domains are useful for abstracting common constraints on fields into a
single location for maintenance. For example, several tables might contain
email address columns, all requiring the same CHECK constraint to verify
the address syntax. Define a domain rather than setting up each table's
constraint individually.


Chamamos isso de empate técnico? :D

[1] http://www.postgresql.org/docs/current/static/sql-createdomain.html





-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Sebastian Webber]

Em 23 de novembro de 2015 14:05, Fernando Cambiaghi 
escreveu:

> Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns
>> testes com o teu volume de dados e avalie qual deles tem um melhor
>> desempenho. Creio eu que comparação de números tende a ser mais eficiente
>> que strings. Teste e voltamos a conversar, ok?
>>
>>
>> Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto
> de vocês, mas gostaria de deixar minha consideração.
>

Não veja isso de forma negativa. Todos aqui podemos aprender auxiliando uns
aos outros. Não importa quão experiente seja.

Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de
validações feito pelo guedes ele já implementa o tipo de dados cpf. e com
isso já facilita a validação do mesmo como numeric.



> Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e
> não tenho ideia do trabalho que daria para alterar, mas fiz uns testes
> baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está
> o resultado:
>
> select 'bigint', pg_size_pretty( sum(pg_column_size(
> 99::bigint )) )
> union
> select 'char_14', pg_size_pretty( sum(pg_column_size(
> '99'::char(14) )) )
> union
> select 'char_20', pg_size_pretty( sum(pg_column_size(
> '99'::char(20) )) );
>
> char_14  : 18 bytes
> char_20  : 24 bytes
> bigint  :  8 bytes
>


:D


>
> Achei interessante, e vai de encontro a resposta do Sebastian quanto a
> usar numéricos.
>

Faça o teste da comparação e veja qual é mais eficiente.

Com fatos, fica fácil tomar a escolha correta. Ou pelo menos ter uma idéia
de qual seria a solução ideal.


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Dickson S. Guedes]

On Mon, Nov 23, 2015 at 02:05:22PM -0200, Fernando Cambiaghi wrote:
> > Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns
> > testes com o teu volume de dados e avalie qual deles tem um melhor
> > desempenho. Creio eu que comparação de números tende a ser mais eficiente
> > que strings. Teste e voltamos a conversar, ok?
> >
> >
>
> Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto
> de vocês, mas gostaria de deixar minha consideração.
> Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e
> não tenho ideia do trabalho que daria para alterar, mas fiz uns testes
> baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está
> o resultado:
> 
> select 'bigint', pg_size_pretty( sum(pg_column_size( 99::bigint
> )) )
> union
> select 'char_14', pg_size_pretty( sum(pg_column_size(
> '99'::char(14) )) )
> union
> select 'char_20', pg_size_pretty( sum(pg_column_size(
> '99'::char(20) )) );
> 
> char_14  : 18 bytes
> char_20  : 24 bytes
> bigint  :  8 bytes
> 
> Achei interessante, e vai de encontro a resposta do Sebastian quanto a usar
> numéricos.

Ola Fernando,

Eu li a sua premissa e a sua conclusão e não entendi, mas acho que voce quis
dizer que vai _ao_ encontro da resposta do Sebastian, já que, pelo que eu
entendi, vocẽ esta concordando com ele. Seria isso?

Outra coisa, voce chegou a testar com numeric(14) e ver o impacto? Voce pode
testar com numeros aleatorios tambem para avaliar. Se o fizer poste o resultado
para conhecimento de todos.

Em tempo, todos somos amadores e ignorantes em muitas coisas e mesmo assim
sempre poderemos contribuir com algo, por mais simples que seja.

[]s
Guedes


signature.asc
Description: Digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Dickson S. Guedes]

Em 21 de novembro de 2015 18:14, Flavio Henrique Araque Gurgel
 escreveu:
>
> http://pgxn.org/dist/validadores/

Esta extensão é antiga, criei ela no PGBR 2011 como demonstração e no
PGDay PR publiquei a mesma na PGXN em caráter de demonstração também.
Mas estamos em 2015 então criei vergonha na cara e coloquei o projeto
no Github [1] para quem quiser contribuir. :D


[1] https://github.com/guedes/validadores

Obrigado!
-- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Tipos de dados

[Gerdan Rezende dos Santos]

Cpf com zero?? O meu comeca assim 001... Te respondi???

Transformação no banco custa, banco e pra armazanar e consultar, quer
deixar bonito bota na aplicacao, se a mascara for executada no cliente
melhor ainda...

Pq usar char?? Poderia comecar te dizendo pra ser ter um padrão no seu
armazanamento...

Ah qto a você me sacanear...  Sua preoculpação deveria ser em ajudar ao
colega, aliás informação aqui ele terá muita, cabe a ele decidir o que
melhor cabe no fim que ele precisa, até pq eu não sou dono da verdade!

-- 
T.'.A.'.F.'.,
*Gerdan Rezende dos Santos *
*Po*stgreSQL & EnterpriseDB Specialist, Support, Training & Services
+55 (61) 9645-1525





Em sábado, 21 de novembro de 2015, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org > escreveu:

> Le 21 nov. 2015 18:19, "Gerdan Rezende dos Santos"  a
> écrit :
> >
> > Lembre-se dos cpf que comecam com 0!
>
> Que têm?  É questão de apresentação, não armazenamento.
>
> > Segundo ponto para mim:  o que é mais escasso disco ou processador?
> > Depende do volume de acesso quantidade de informação, etc!
>
> Sim, óbvio, e daí?  Não estou sacaneando, só quero saber onde você quer
> chegar?
>
> > Costumos usar um char(numero extado) pra guardar este tipo de
> informacao!
>
> Como já disse, legal compartilhar experiências, mas é melhor ainda dizer
> as razões e as conseqüências.
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>


-- 
T.'.A.'.F.'.,
*Gerdan Rezende dos Santos *
*Po*stgreSQL & EnterpriseDB Specialist, Support, Training & Services
+55 (61) 9645-1525
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Sebastian Webber]

Em 21 de novembro de 2015 10:03, Luciano Reis 
escreveu:

> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
> monetários e encontrei opiniões muito diversas uns defendem que CPF tem de
> ser guardado como string outros não.
> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
> tomar essa decisão, como não encontrei nada concreto e fundamentado estou
> recorrendo a comunidade.
>

Complemento o email de todos citando duas URLs que creio que vão te ajudar
no teu problema.

A primeira URL é uma função pra validar o CPF[1], escrita pelo Euler.

A segunda URL é uma discussão antiga[2], com o mesmo dilema e drama dessa
aqui.

Quanto a minha opinião:

Salve os dados em numeros e formate os dados como string apenas quando
necessário. Caso queiras validar no insert, crie uma constraint de check e
chame a função que citei. Talvez ela precise algum ajuste pra receber os
dados como numero e não texto.

Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns
testes com o teu volume de dados e avalie qual deles tem um melhor
desempenho. Creio eu que comparação de números tende a ser mais eficiente
que strings. Teste e voltamos a conversar, ok?


[]'s

[1] https://wiki.postgresql.org/wiki/CPF
[2] http://postgresql.nabble.com/Mascara-de-CPF-td2027551.html


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Danilo Silva]

Em 21 de novembro de 2015 13:05, Tiago José Adami 
escreveu:

> Em 21 de novembro de 2015 11:26, Osvaldo Kussama
>  escreveu:
> > Em 21/11/15, Luciano Reis escreveu:
> >> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
> >> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
> >> monetários e encontrei opiniões muito diversas uns defendem que CPF tem
> de
> >> ser guardado como string outros não.
> >> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
> >> tomar essa decisão, como não encontrei nada concreto e fundamentado
> estou
> >> recorrendo a comunidade.
> >
> > Creio que todos estes campos sejam numéricos e portanto devem ser
> > armazenados como números (inteiro ou decimal de precisão arbitrária).
>
> Eu pratico a seguinte regra: mesmo que o valor seja numérico, se não
> for utilizado para cálculos matemáticos e não for monetário, eu
> prefiro armazenar em VARCHAR, e geralmente com um limite maior do que
> o atributo exige: para CPF e CNPJ eu uso VARCHAR(20), por exemplo.
>
> ​Costumo usar um campo varchar(14) para considerar CPF e CNPJ, onde o dado
é gravado já formato, retirando-se os pontos e traços, etc. Também utilizo
uma CHECK CONSTRAINT para garantir que sejam gravados dados com 11 ou 14
digitos, ou seja, dados com quantidade de digitos diferentes de 11 e 14 não
serão gravados.

​Devemos considerar que o tipo de dado INT não é recomendado para guardar
informações como CPF e CNPJ, pois caso a informação contenha zeros a
esquerda, esses zeros serão ignorados e não teremos uma informação íntegra.

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Leandro Guimarães Faria Corcete DUTRA]

Le 21 novembre 2015 14:31:10 GMT-02:00, Danilo Silva 
 a écrit :
>>
> ​Costumo usar um campo varchar(14) para considerar CPF e CNPJ, onde o
>dado
>é gravado já formato, retirando-se os pontos e traços, etc.

Não entendi.  Já formatado mas sem pontos, traços ?  Como assim?


> Também utilizo
>uma CHECK CONSTRAINT para garantir que sejam gravados dados com 11 ou
>14 digitos

Isso não é suficiente.  Use as funções de validação presentes por exemplo no 
CPAN.


>​Devemos considerar que o tipo de dado INT não é recomendado para
>guardar
>informações como CPF e CNPJ, pois caso a informação contenha zeros a
>esquerda, esses zeros serão ignorados e não teremos uma informação
>íntegra.

Não entendi.  Zeros à esquerda são questão apenas de apresentação, o que teria 
a ver com integridade?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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] Tipos de dados

[Reijanio Nunes Ribeiro]

Eu sempre deixo como string(varchar) esse tipo de campo
Em 21/11/2015 10:03, "Luciano Reis"  escreveu:

> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
> monetários e encontrei opiniões muito diversas uns defendem que CPF tem de
> ser guardado como string outros não.
> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
> tomar essa decisão, como não encontrei nada concreto e fundamentado estou
> recorrendo a comunidade.
>
> Att,
> Luciano Reis.
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Osvaldo Kussama]

Em 21/11/15, Luciano Reis escreveu:
> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
> monetários e encontrei opiniões muito diversas uns defendem que CPF tem de
> ser guardado como string outros não.
> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
> tomar essa decisão, como não encontrei nada concreto e fundamentado estou
> recorrendo a comunidade.
>


Creio que todos estes campos sejam numéricos e portanto devem ser
armazenados como números (inteiro ou decimal de precisão arbitrária).

Algumas vezes que li a justificativa de se utilizar strings me pareceu
que havia uma grande confusão entre formato de armazenamento e formato
de exibição. Por ex. como o CPF normalmente é exibido na forma:
99.999.999-99 julgava-se que seria melhor já armazena-lo dessa forma,
contudo a função to_char permite formatar números no formato que
quiser.

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Tiago José Adami]

Em 21 de novembro de 2015 11:26, Osvaldo Kussama
 escreveu:
> Em 21/11/15, Luciano Reis escreveu:
>> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
>> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
>> monetários e encontrei opiniões muito diversas uns defendem que CPF tem de
>> ser guardado como string outros não.
>> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
>> tomar essa decisão, como não encontrei nada concreto e fundamentado estou
>> recorrendo a comunidade.
>
> Creio que todos estes campos sejam numéricos e portanto devem ser
> armazenados como números (inteiro ou decimal de precisão arbitrária).

Eu pratico a seguinte regra: mesmo que o valor seja numérico, se não
for utilizado para cálculos matemáticos e não for monetário, eu
prefiro armazenar em VARCHAR, e geralmente com um limite maior do que
o atributo exige: para CPF e CNPJ eu uso VARCHAR(20), por exemplo.

Já me deparei com casos onde todos os envolvidos no projeto juravam
que não poderia haver caracteres - não númericos - no valor, como por
exemplo RG e conta bancária. De repente apareceram identificadores de
RG antigos com uma letra e contas de um banco que tinham um "X" como
dígito verificador.

Esta abordagem permite gravar "lixo" no campo, como os traços, pontos,
etc. Mas ainda prefiro criar e manter uma validação para proibir os
caracteres inválidos do que correr o risco de ter que alterar o tipo
da coluna e as variáveis de programa (aplicativos e sistemas) no
futuro.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Flávio Silveira]

On 21/11/2015 13:05, Tiago José Adami wrote:

Eu pratico a seguinte regra: mesmo que o valor seja numérico, se não
for utilizado para cálculos matemáticos e não for monetário, eu
prefiro armazenar em VARCHAR, e geralmente com um limite maior do que
o atributo exige: para CPF e CNPJ eu uso VARCHAR(20), por exemplo.

Já me deparei com casos onde todos os envolvidos no projeto juravam
que não poderia haver caracteres - não númericos - no valor, como por
exemplo RG e conta bancária. De repente apareceram identificadores de
RG antigos com uma letra e contas de um banco que tinham um "X" como
dígito verificador.

Esta abordagem permite gravar "lixo" no campo, como os traços, pontos,
etc. Mas ainda prefiro criar e manter uma validação para proibir os
caracteres inválidos do que correr o risco de ter que alterar o tipo
da coluna e as variáveis de programa (aplicativos e sistemas) no
futuro.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Boa tarde,

  Eu também aprendi dessa forma, parafraseando meu professor: De 
maneira geral, se o campo não for utilizado em cálculo, deve ser string 
(char, varchar).


  Mas lendo os comentários subsequentes vi que pode não ser a maneira 
mais correta. Meu professor dava originalmente a matéria Engenharia de 
Software e foi transferido para Banco de Dados, talvez por essa razão 
ele tenha mais essa visão do programador.


  Agradeço ao pessoal da lista por expor práticas melhores.

Atenciosamente,
  Flávio Silveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Gerdan Rezende dos Santos]

Lembre-se dos cpf que comecam com 0!

Segundo ponto para mim:  o que é mais escasso disco ou processador?
Depende do volume de acesso quantidade de informação, etc!

Costumos usar um char(numero extado) pra guardar este tipo de informacao!


Em sábado, 21 de novembro de 2015, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
> Aliás, um bom projeto para a comunidade brasileira seria criar tipos de
> dados RG, CEP, CNPJ, CPF...
>
>
> http://pgxn.org/dist/validadores/
>
> []s
>
> Flavio Gurgel
>
>
>

-- 
T.'.A.'.F.'.,
*Gerdan Rezende dos Santos *
*Po*stgreSQL & EnterpriseDB Specialist, Support, Training & Services
+55 (61) 9645-1525
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

Le 21 nov. 2015 18:19, "Gerdan Rezende dos Santos"  a
écrit :
>
> Lembre-se dos cpf que comecam com 0!

Que têm?  É questão de apresentação, não armazenamento.

> Segundo ponto para mim:  o que é mais escasso disco ou processador?
> Depende do volume de acesso quantidade de informação, etc!

Sim, óbvio, e daí?  Não estou sacaneando, só quero saber onde você quer
chegar?

> Costumos usar um char(numero extado) pra guardar este tipo de informacao!

Como já disse, legal compartilhar experiências, mas é melhor ainda dizer as
razões e as conseqüências.

-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] Tipos de dados

[Leandro Guimarães Faria Corcete DUTRA]

Le 21 novembre 2015 17:49:32 GMT-02:00, "Flávio Silveira"  a 
écrit :
>
>   Mas lendo os comentários subsequentes vi que pode não ser a maneira 
>mais correta.

Eu diria mais que ser ou não correta, é meio irrelevante.  O relevante é criar 
um domínio com restrição de validação.

Aliás, um bom projeto para a comunidade brasileira seria criar tipos de dados 
RG, CEP, CNPJ, CPF...


> Meu professor dava originalmente a matéria Engenharia de 
>Software e foi transferido para Banco de Dados, talvez por essa razão 
>ele tenha mais essa visão do programador.

A verdade é que pouquíssimos professores brasileiros sequer sabem o que é o 
modelo relacional, como quem está aqui tempo já deve ter constatado com meus 
desafios... :-(



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/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] Tipos de dados

[Flavio Henrique Araque Gurgel]

Aliás, um bom projeto para a comunidade brasileira seria criar tipos de
dados RG, CEP, CNPJ, CPF...


http://pgxn.org/dist/validadores/

[]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] Tipos de dados

[Leandro GFC DUTRA]

Le 21 novembre 2015 10:03:41 GMT-02:00, Luciano Reis 
 a écrit :
>Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
>específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e
>valores
>monetários e encontrei opiniões muito diversas uns defendem que CPF tem
>de
>ser guardado como string outros não.

Esse ‘não’ aí está muito genérico… que outras possibilidades consideraste?


>É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
>tomar essa decisão, como não encontrei nada concreto e fundamentado
>estou
>recorrendo a comunidade.

Faz bem.

Mas essa questão é maior que o PostgreSQL, é de conceitos fundamentais: de 
maneira geral, devemos guardar cada tipo de dados da maneira mais específica
possível.

Já discutimos isso aqui antes, pode procurar detalhes nos arquivos de histórico 
da lista.  Mas essencialmente, a menos que alguém já tenha criado um tipo de 
dados específico, o mais prático será criar um DOMAIN com CHECK CONSTRAINT que 
use uma função em linguagem externa fazendo uso de uma biblioteca de validação. 
 Sei que havia tais funções de validação de dados brasileiros em Perl no CPAN, 
imagino que haja em Python também.



-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk:xmpp:leand...@jabber.org
+55 (61) 9302 2691        ICQ/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] tipos de dados

[Pedro Costa]

Em 01-02-2012 18:27, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 o decimal e numeric não funcionam
 Funcionam, sim.  Como testaste, e que resultados obtiveste?
Tenho a última versão. Tentei alter table ruas add column numeric (2,2)

Mas depois diz que não podem ser números superiores a um...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2012/2/3 Pedro Costa pedrocostaa...@sapo.pt:
 Em 01-02-2012 18:27, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 o decimal e numeric não funcionam
 Funcionam, sim.  Como testaste, e que resultados obtiveste?
 Tenho a última versão. Tentei alter table ruas add column numeric (2,2)

O atributo não tem nome?


 Mas depois diz que não podem ser números superiores a um...

Depois do quê?  Qual o texto exato da resposta?  Se for uma inserção
de dados, é porque especificaste números entre −0,99 e 0,99.  Creio
que o que queres é NUMERIC (4,2).
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] tipos de dados

[Pedro Costa]

Já agora, eu tenho campos double precision e quero que o número de casa 
decimais sejam duas, é possível restringir?
Ou que tipo de dados tem de ser? Experimentei numeric e decimal mas só 
funciona com números inferiores a 1...


Obrigado
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2012/2/1 Pedro Costa pedrocostaa...@sapo.pt:
 Já agora, eu tenho campos double precision e quero que o número de casa
 decimais sejam duas, é possível restringir?

Não está claro… restringir entrada, armazenamento ou saída?

São mecanismos diferentes para cada situação.  O mais genérico seria
alterar o tipo de dados.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] tipos de dados

[Pedro Costa]

Em 01-02-2012 16:09, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 restringir entrada, armazenamento ou saída?


Armazenamento e saída ou apenas saída
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] tipos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2012/2/1 Pedro Costa pedrocostaa...@sapo.pt:
 Em 01-02-2012 16:09, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 restringir entrada, armazenamento ou saída?

 Armazenamento e saída ou apenas saída

Então usa um tipo de dado adequado…
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] tipos de dados

[Pedro Costa]

Sim mas qual?como limito o double precision?o decimal e numeric não 
funcionam


Em 01-02-2012 16:28, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 2012/2/1 Pedro Costapedrocostaa...@sapo.pt:
 Em 01-02-2012 16:09, Guimarães Faria Corcete DUTRA, Leandro escreveu:
 restringir entrada, armazenamento ou saída?
 Armazenamento e saída ou apenas saída
 Então usa um tipo de dado adequado…
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral