[python-brasil] Separar campo endereço e número do endereço
Ale
Estamos migrando de ERP aqui na empresa e no sistema atual o campo
endereço é unico, ou seja, o cara digita endereço, numero e
complemento tudo em apenas um campo.
O outro ERP esses campos estão separados em 3 , endereço, numero,
complemento respectivamente.
Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
que não dá para atender 100% dos casos, mas quero tentar amenizar bem
esse retrabalho.
Reparei que a maior parte do cadastro tem uma virgula separando o
endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
usam S/N quando não tem um número..
Estou pensando em fazer um split e sair procurando pelos termos mais
comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
Obrigado,
Alessandro
------------------------------------
,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia: |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
| E se você é usuário do BOL lembre-se de cadastrar o |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/python-brasil/
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Marco André Lopes Mendes
coding dojo. O interessante dessa abordagem seria tentar cobrir todos os
tipos de registros que você tem. Tente colocar um pedaço do arquivo de dados
num paste.bin pro pessoal ver o formato e tentar ajudar.
[]s
Marco André
2010/11/10 Ale <alessand...@gmail.com>
> Bom dia pessoal,
>
> Estamos migrando de ERP aqui na empresa e no sistema atual o campo
> endereço é unico, ou seja, o cara digita endereço, numero e
> complemento tudo em apenas um campo.
>
> O outro ERP esses campos estão separados em 3 , endereço, numero,
> complemento respectivamente.
>
> Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
> que não dá para atender 100% dos casos, mas quero tentar amenizar bem
> esse retrabalho.
>
> Reparei que a maior parte do cadastro tem uma virgula separando o
> endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
> usam S/N quando não tem um número..
>
> Estou pensando em fazer um split e sair procurando pelos termos mais
> comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
>
> Obrigado,
> Alessandro
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia: |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> | E se você é usuário do BOL lembre-se de cadastrar o |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do
> Yahoo! Grupos
>
>
>
--
Marco André
marco...@gmail.com
http://www.google.com.br/profiles/marcoandre
[As partes desta mensagem que não continham texto foram removidas]
Alessandro Aguiar
cadastro de cliente é imenso.
obrigado,
Alessandro
2010/11/10 Marco André Lopes Mendes <marco...@gmail.com>
>
>
> Eu achei um bom exemplo pra trabalhar com teste unitário e até pra fazer um
> coding dojo. O interessante dessa abordagem seria tentar cobrir todos os
> tipos de registros que você tem. Tente colocar um pedaço do arquivo de
> dados
> num paste.bin pro pessoal ver o formato e tentar ajudar.
>
> []s
>
> Marco André
>
> 2010/11/10 Ale <alessand...@gmail.com<alessandro.aguiar%40gmail.com>
> >
>
>
> > Bom dia pessoal,
> >
> > Estamos migrando de ERP aqui na empresa e no sistema atual o campo
> > endereço é unico, ou seja, o cara digita endereço, numero e
> > complemento tudo em apenas um campo.
> >
> > O outro ERP esses campos estão separados em 3 , endereço, numero,
> > complemento respectivamente.
> >
> > Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
> > que não dá para atender 100% dos casos, mas quero tentar amenizar bem
> > esse retrabalho.
> >
> > Reparei que a maior parte do cadastro tem uma virgula separando o
> > endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
> > usam S/N quando não tem um número..
> >
> > Estou pensando em fazer um split e sair procurando pelos termos mais
> > comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
> >
> > Obrigado,
> > Alessandro
> >
> >
> > ------------------------------------
>
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia: |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > | E se você é usuário do BOL lembre-se de cadastrar o |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do
> > Yahoo! Grupos
> >
> >
> >
>
> --
> Marco André
> marco...@gmail.com <marcoandre%40gmail.com>
Alessandro Aguiar
reais mesmo ok.. Esses endereços que terei que splitar nos 3 campos ditos.
[]s
Alessandro
2010/11/10 Marco André Lopes Mendes <marco...@gmail.com>
>
>
> Eu achei um bom exemplo pra trabalhar com teste unitário e até pra fazer um
> coding dojo. O interessante dessa abordagem seria tentar cobrir todos os
> tipos de registros que você tem. Tente colocar um pedaço do arquivo de
> dados
> num paste.bin pro pessoal ver o formato e tentar ajudar.
>
> []s
>
> Marco André
>
> 2010/11/10 Ale <alessand...@gmail.com<alessandro.aguiar%40gmail.com>
> >
>
>
> > Bom dia pessoal,
> >
> > Estamos migrando de ERP aqui na empresa e no sistema atual o campo
> > endereço é unico, ou seja, o cara digita endereço, numero e
> > complemento tudo em apenas um campo.
> >
> > O outro ERP esses campos estão separados em 3 , endereço, numero,
> > complemento respectivamente.
> >
> > Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
> > que não dá para atender 100% dos casos, mas quero tentar amenizar bem
> > esse retrabalho.
> >
> > Reparei que a maior parte do cadastro tem uma virgula separando o
> > endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
> > usam S/N quando não tem um número..
> >
> > Estou pensando em fazer um split e sair procurando pelos termos mais
> > comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
> >
> > Obrigado,
> > Alessandro
> >
> >
> > ------------------------------------
>
> >
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia: |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > | E se você é usuário do BOL lembre-se de cadastrar o |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´Links do
> > Yahoo! Grupos
> >
> >
> >
>
> --
> Marco André
> marco...@gmail.com <marcoandre%40gmail.com>
Junior Polegato - Linux
> Boa tarde Marco, segue ai no link exemplo de alguns exemplos que falei. São
> reais mesmo ok.. Esses endereços que terei que splitar nos 3 campos ditos.
> http://pastebin.com/AtUzCUHD
>
Olá!
Interessante, tenho um caso parecido, precisamos partir de uma
documentação, vamos então a minha ideia inicial:
0. Normalizar os endereços tirando os acentos e deixando tudo com letras
maiúsculas
1. Tipo de logradouro
1.1. Os tipos bem definidos pelos correios estão em
http://www.buscacep.correios.com.br/servicos/dnec/index.do
1.1.1. Do código da página, tem-se uma lista de 44 tipos por extenso e
com acentos
1.1.2. Normalizar estes tirando os acentos e deixando tudo com letras
maiúsculas
1.1.3. Para cada tipo de logradouro em cada linha, escrever as possíveis
abreviaturas separadas por espaço. Ex.: 10 RUA R
1.1.4. Acima criamos uma tabela com código, tipo de logradouro,
abreveatura 1, abreveatura 2...
1.2. Para cada endereço dado, a primeira palavra será o tipo de
logradouro, onde esta é delimitada por qualquer caracter que não seja
letra maiúscula
1.3. Para cada tipo de logradouro encontrado, verificar se este está
entre algum na tabela de tipos de logradouros
1.3.1. Se estiver, já temos o tipo de logradouro bem definido e o que
segue será o logradouro, número e complemento
1.3.2. Se não estiver, então podemos considerar tipo de logradouro nulo
e esta palavra fará parte do logradouro
2. Logradouro, número e complemento
2.1. Depois do tipo de logradouro, pelo menos a primeira palavra é do
logradouro e devemos encontrar o limitador deste após esta palavra
2.1.1. Se o tipo for rodovia, devemos procurar por KM, e este com o
número que o segue será o número, o restante será o complemento
2.1.2. Se o tipo não for rodovia, procurar por uma palavra que seja
iniciada por números
2.1.2.1. Se precedida por Q, QUADRA, QD, CJ, dentre outros a analisar,
será sem número, e teremos apenas logradouro e complemento separados na
palavra que precede
2.1.2.2. Se precedida por vírgula, NR, NR., N, N., NO, NO., dentre
outros a analisar, este será o número, a palavra que precede será
ignorada, sendo o logradouro o resto anterior e o complemento o resto
posterior
2.2. Devemos tirar espaços e pontuação excedentes no logradouro, número
e complemento
Por enquanto é isso que tenho na caixola. Veja que se não quiser separar
o tipo de logradouro, ignore o passo 1 e vá somente para o 2.
[]'s
Junior Polegato
Carlos Ribeiro
gente precisa "reinventar" o tempo todo!
Obs: já fiz isso usando regras como as propostas pelo Junior, mas na
prática, tem muita coisa que precisa de "heurísticas". Uma abordagem tipo
"Google Translate" poderia ajudar!
Carlos Ribeiro
2010/11/10 Junior Polegato - Linux <li...@juniorpolegato.com.br>
--
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carri...@gmail.com
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Carlos Ribeiro
dos correios?
Daria para fazer algo do tipo no App Engine!
Carlos Ribeiro
2010/11/10 Carlos Ribeiro <carri...@gmail.com>
Alessandro Aguiar
boa idéia Carlos, ai podiamos ter a opção de informar um arquivo texto, ou
csv para o programa e ele importaria isso e faria as conversões (sei lá,
algo bem minimalista mesmo na interface). Seria legal termos uma tabela onde
teríamos o campo endereço original e os 3 novos campos resultantes da nossa
conversão, teríamos também um form em que visualizassemos e que pudessemos
dar manutenção nisso.
Ontem eu fiz uns testes aqui para achar o tipo de logradouro no endereço,
coincidentemente ele segue mais ou menos a abordagem do Junior. Eu usei
conjuntos para achar um determinado tipo de logradouro no endereço, fazendo
a interseção do endereço (eu fiz um split do mesmo e o transformei em
conjunto) com os tipos de logradouros e até que funcionou certinho.. Mas
isso era só experimental mesmo, não sei se isso seria a melhor solução. É
que eu estava dando uma olhada em set do python..
Vamos nessa então?
Valeu,
Alessandro
2010/11/10 Carlos Ribeiro <carri...@gmail.com>
Carlos Ribeiro
existem casos "limite" em que um mesmo endereço poderia, potencialmente, ser
interpretado de forma ambígua, devido a diferentes padrões em cidades/locais
diferentes. É por isso que eu acho que uma abordagem mais "heurística", com
um "treinamento" a partir de uma base de carga inicial, pode ser mais
interessante.
Carlos Ribeiro
2010/11/11 Alessandro Aguiar <alessand...@gmail.com>
Junior Polegato - Linux
> Já fiz isso com REs. Mas sempre sobra muita coisa pra limpar na mão. Também
> existem casos "limite" em que um mesmo endereço poderia, potencialmente, ser
> interpretado de forma ambígua, devido a diferentes padrões em cidades/locais
> diferentes. É por isso que eu acho que uma abordagem mais "heurística", com
> um "treinamento" a partir de uma base de carga inicial, pode ser mais
> interessante.
> Carlos Ribeiro
>
Olá!
Dei o pontapé inicial, acho que no que fiz pego 99% dos casos.
Vale a pena conferir:
http://www.juniorpolegato.com.br/interpretar_enderecos/
[]'s
Junior Polegato
------------------------------------
,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia: |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
| E se você é usuário do BOL lembre-se de cadastrar o |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
Paul Eipper
> Em 11-11-2010 08:34, Carlos Ribeiro escreveu:
>> Já fiz isso com REs. Mas sempre sobra muita coisa pra limpar na mão. Também
>> existem casos "limite" em que um mesmo endereço poderia, potencialmente, ser
>> interpretado de forma ambígua, devido a diferentes padrões em cidades/locais
>> diferentes. É por isso que eu acho que uma abordagem mais "heurística", com
>> um "treinamento" a partir de uma base de carga inicial, pode ser mais
>> interessante.
>> Carlos Ribeiro
>>
>
> Olá!
>
> Dei o pontapé inicial, acho que no que fiz pego 99% dos casos.
> Vale a pena conferir:
>
> http://www.juniorpolegato.com.br/interpretar_enderecos/
>
só uma dica sobre os comentários no código: se você vai usar strings
multiline fechando elas no final da linha e concatenando depois com a
próxima, meio que perde o sentido da coisa toda.
--
Paul Eipper
Alessandro Aguiar
Ficou bem legal o programa e com certeza dessa forma evita bastante
retrabalho mesmo. Eu mexi pouco com o appengine, mas gostei da ideia que foi
dada de fazermos uma aplicação lá, vou tentar fazer isso.
[]s,
Alessandro
2010/11/11 Junior Polegato - Linux <li...@juniorpolegato.com.br>
>
>
> Em 11-11-2010 08:34, Carlos Ribeiro escreveu:
>
> > Já fiz isso com REs. Mas sempre sobra muita coisa pra limpar na mão.
> Também
> > existem casos "limite" em que um mesmo endereço poderia, potencialmente,
> ser
> > interpretado de forma ambígua, devido a diferentes padrões em
> cidades/locais
> > diferentes. É por isso que eu acho que uma abordagem mais "heurística",
> com
> > um "treinamento" a partir de uma base de carga inicial, pode ser mais
> > interessante.
> > Carlos Ribeiro
> >
>
> Olá!
>
> Dei o pontapé inicial, acho que no que fiz pego 99% dos casos.
> Vale a pena conferir:
>
> http://www.juniorpolegato.com.br/interpretar_enderecos/
>
> []'s
> Junior Polegato
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Luciano Ramalho
>> http://www.juniorpolegato.com.br/interpretar_enderecos/
>>
>
> só uma dica sobre os comentários no código: se você vai usar strings
> multiline fechando elas no final da linha e concatenando depois com a
> próxima, meio que perde o sentido da coisa toda.
Concordo Paul, no caso há duas redundâncias: não seria necessário
fechar a string a cada linha, e não seria necessário usar a \ no final
da linha.
Eu acho o sinal \ feioso e até um pouco perigoso (porque se tiver um
espaço em branco depois dele, ele perde o efeito de anular a quebra de
linha).
Então o que eu faço é aproveitar ao máximo o fato de que em Python
nunca é preciso usar a \ dentro de expressões delimitadas por (), {}
ou [], porque nestes contextos o parser do Python é esperto o
suficiente para saber que a linha lógica não acabou. Ou seja, dentro
destes delimitadores o Pyhon considera uma quebra de linha como um
simples espaço. Isso elimina 95% dos casos em que se usaria \ em
outras linguagens.
Outra coisa que é interessante saber é que os códigos abaixo produzem
exatamente o mesmo resultado:
x = "aaabbbccc"
ou
x = ("aaa"
"bbb"
"ccc")
O Paul já sabe tudo isso, estou compartilhando com colegas que
eventualmente ainda não tenham descoberto que o parser do Python é bem
esperto.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Junior Polegato - Linux
> 2010/11/11 Junior Polegato - Linux<li...@juniorpolegato.com.br>:
>
>> Em 11-11-2010 08:34, Carlos Ribeiro escreveu:
>>
>>> Já fiz isso com REs. Mas sempre sobra muita coisa pra limpar na mão. Também
>>> existem casos "limite" em que um mesmo endereço poderia, potencialmente, ser
>>> interpretado de forma ambígua, devido a diferentes padrões em cidades/locais
>>> diferentes. É por isso que eu acho que uma abordagem mais "heurística", com
>>> um "treinamento" a partir de uma base de carga inicial, pode ser mais
>>> interessante.
>>>
>> Vale a pena conferir:
>> http://www.juniorpolegato.com.br/interpretar_enderecos/
>>
> só uma dica sobre os comentários no código: se você vai usar strings
> multiline fechando elas no final da linha e concatenando depois com a
> próxima, meio que perde o sentido da coisa toda.
>
Olá Paul,
Isso eu sei, mas vamos ao real problema, e minhas ponderações
para ter feito isso e quem sabem você ou alguém da lista tenha uma
sugestão melhor...
Primeiro, usei multiline e fiz a documentação das funções em
várias linhas para não ficar muito comprido para ler, porém com
multiline a quebra de linha e espaços para alinhamento vão fazer parte
da string, algo que eu não queria, veja (trocar ponto no início por espaço):
def teste():
...."""Primeira Linha
.......Segudna Linha
.......Terceira Linha"""
....pass
print teste.__doc__
Primeira Linha
.......Segudna Linha
.......Terceira Linha
Na verdade eu queria que saísse "Primeira Linha Segunda Linha
Terceira Linha", como resolver isso? Então fechei a string no final com
o devido espaço para separa para a próxima linha e concatenei com \ para
a próxima string abaixo, tem jeito melhor?
Sobre ter usado multiline e concatenar as strings, não faz
sentido se focar somente me multiline, mas se pensar que não preciso
escapar ' ou ", escrevo o comentário mais a vontade, sem contar que já
estava escrito e podia ter ' ou " e eu teria que ficar escapando...
Quanto ao \ no final, como um colega sugeriu, pode-se usar
"(<várias strings em várias linha>)" e uso quando quero atribuir a uma
variável, mas no caso do comentário achei meio estranho fazer assim,
então usei o \, questão de paladar apenas...
Tem alguma sugestão melhor? Posso usar multiline para não ficar
escapando ' ou " ou isso não se deve fazer de forma alguma?
[]'s
Junior Polegato
Leonardo Santagada
> Na verdade eu queria que saísse "Primeira Linha Segunda Linha
> Terceira Linha", como resolver isso? Então fechei a string no final com
> o devido espaço para separa para a próxima linha e concatenei com \ para
> a próxima string abaixo, tem jeito melhor?
>
O luciano já deu um jeito melhor, e tem um jeito usando uma função
que tira esses espaços do começo da linha, eu sempre esqueço onde ela
fica acho que o nome é textunwrap ou algo assim.
--
Leonardo Santagada
Paul Eipper
Se você quer imprimir as docstrings, você tem que parsear elas do
jeito certo, e não estragar seu código pra fazer o print funcionar.
De qualquer forma, tente isso:
import pydoc
print pydoc.getdoc(teste)
ele já faz o trabalho pra você :)
--
Paul Eipper
Junior Polegato - Linux
> 2010/11/12 Junior Polegato - Linux<li...@juniorpolegato.com.br>:
>
> jeito certo, e não estragar seu código pra fazer o print funcionar.
> De qualquer forma, tente isso:
>
> import pydoc
> print pydoc.getdoc(teste)
>
> ele já faz o trabalho pra você :)
>
Entendi, para usufruir da __doc__ use comandos que sabem o que fazer com
ela. Mas eu venho do bom e velho e atual C++ onde documento antes das
funções como comentário mesmo e mais ao estilo do Doxygen, pois em C++
não tem o __doc__ que tem no Python, dai esses "garranchos"...
Eu não quero usar o __doc__, apenas quis deixar de uma forma que ficasse
bem no código e bem para quem desse um "print teste.__doc__" ou ainda
"print pydoc.getdoc(teste)" e não quebrasse a linha, mas pelo que vi
essa quebra não deveria ser preocupação minha, apenas tenho que fazer a
documentação multiline sem me preocupar com isso, sendo que quem for
fazer uso do __doc__ que tem que tratar a saída...
Vou corrigir essas docs e mais outras adequações de complemento emendado
ao número e posto uma nova versão.
Obrigado.
[]'s
Junior Polegato
Alessandro Aguiar
e um probleminha aqui no seguinte registro
RODOVIA MG 252 - KM
ou seja, quando temos um tipo de logradouro Rodovia e um KM sem o número..
Acredito que isso tenha sido erro no cadastro, mas infelizmente o cadastro
aqui esta bem bagunçado, por um lado é bom, pois temos muita bizarrice para
testes.. ehehehe
Valeu,
Alessandro
2010/11/12 Junior Polegato - Linux <li...@juniorpolegato.com.br>
>
>
> Em 12-11-2010 13:52, Paul Eipper escreveu:
>
> > 2010/11/12 Junior Polegato - Linux<li...@juniorpolegato.com.br<linux%40juniorpolegato.com.br>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Luciano Ramalho
> boa tarde Junior, rodei o programa que você fez com uma outra massa de teste
> e um probleminha aqui no seguinte registro
>
> RODOVIA MG 252 - KM
>
> ou seja, quando temos um tipo de logradouro Rodovia e um KM sem o número..
> Acredito que isso tenha sido erro no cadastro, mas infelizmente o cadastro
> aqui esta bem bagunçado, por um lado é bom, pois temos muita bizarrice para
> testes.. ehehehe
Existe um velho ditado em informática que diz "entra lixo, sai lixo"
(garbage in, garbage out).
Esse dado que você citou é inútil como endereço, não tem como
consertá-lo, né Alessandro?
Estes dias eu andei refletindo sobre estratégias para lidar com dados
mal-formados, e saquei que a função unicode [1] do Python oferece um
padrão muito interessante de tratamento de anomalias, o argumento
errors:
unicode([object[, encoding[, errors]]])
[1] http://docs.python.org/library/functions.html#unicode
O argumento errors pode ser uma destas strings, que determinam o
comportamento da função de conversão quando há um problema na entrada:
- 'strict': levanta uma exceção (o default)
- 'ignore': ignora sileciosamente (despreza) os caracteres inválidos
- 'replace': substitui os caracteres inválidos por um marcador
especial constante
Eu já conhecia estas opções, a idéia que foi novidade para mim é que
opções como estas podem ser usadas de forma quase universal em
qualquer rotina que faz conversão de dados de um formato para outro.
Porque não dá para o programador decidir em nome do usuário qual é o
melhor comportamento, pois depende do contexto de uso da rotina.
Por exemplo, em uma conversão de massa de dados legada, talvez o
melhor seja usar um comportamento tipo "replace" onde você não
interrompe o processo de migração a cada erro. Mas uma vez o legado
migrado, o sistema pode passar a fazer importação em modo strict para
evitar a entrada de novos erros na base de dados.
No módulo codecs [2] as opções 'strict', 'ignore' e 'replace' são
complementadas por mais duas: 'xmlcharrefreplace' e 'backslashreplace'
que fazem substituições sem perda de dados, e há ainda a possibilidade
de registrar uma função de tratamento de erros que é invocada quando
algo inesperado ocorre nos dados [3].
[2] http://docs.python.org/library/codecs.html#module-codecs
[3] http://docs.python.org/library/codecs.html#codecs.register_error
Estou usando essas idéias para implementar rotinas de conversão de
dados semiestruturados de bases CDS/ISIS para CouchDB, que é o tema do
meu TCC.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Eldio Santos Jr.
Mas enfim, indo direto ao ponto, gostaria de saber se posso utilizar
este exemplo em um grupo de estudos que participo, a principio pensei
em usar os dados que passou como exemplo, porém se houver algum
problema devido a questões de privacidade ou sigilo dos dados da
empresa me avise que gero uma massa fictícia seguindo os padrões do
que você passou...
Em 10/11/2010, Ale<alessand...@gmail.com> escreveu:
> Bom dia pessoal,
>
> Estamos migrando de ERP aqui na empresa e no sistema atual o campo
> endereço é unico, ou seja, o cara digita endereço, numero e
> complemento tudo em apenas um campo.
>
> O outro ERP esses campos estão separados em 3 , endereço, numero,
> complemento respectivamente.
>
> Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
> que não dá para atender 100% dos casos, mas quero tentar amenizar bem
> esse retrabalho.
>
> Reparei que a maior parte do cadastro tem uma virgula separando o
> endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
> usam S/N quando não tem um número..
>
> Estou pensando em fazer um split e sair procurando pelos termos mais
> comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
>
> Obrigado,
> Alessandro
>
--
Enviado do meu celular
________________
Eldio Santos Junior
Tel.: (21) 8884-3757
Skype: eldiojr
Twitter: @eldius
Email/GTalk: eldio...@gmail.com
Alessandro Aguiar
Valeu,
Alessandro
2010/11/15 Eldio Santos Jr. <eldio...@gmail.com>
>
>
> Rapaz, a questão é bem interessante... Ainda não pder toda a thread...
> Mas enfim, indo direto ao ponto, gostaria de saber se posso utilizar
> este exemplo em um grupo de estudos que participo, a principio pensei
> em usar os dados que passou como exemplo, porém se houver algum
> problema devido a questões de privacidade ou sigilo dos dados da
> empresa me avise que gero uma massa fictícia seguindo os padrões do
> que você passou...
>
> Em 10/11/2010, Ale<alessand...@gmail.com<alessandro.aguiar%40gmail.com>>
> escreveu:
> > Bom dia pessoal,
> >
> > Estamos migrando de ERP aqui na empresa e no sistema atual o campo
> > endereço é unico, ou seja, o cara digita endereço, numero e
> > complemento tudo em apenas um campo.
> >
> > O outro ERP esses campos estão separados em 3 , endereço, numero,
> > complemento respectivamente.
> >
> > Pergunta: Alguém já fez uma rotina que faça essa quebra, claro que sei
> > que não dá para atender 100% dos casos, mas quero tentar amenizar bem
> > esse retrabalho.
> >
> > Reparei que a maior parte do cadastro tem uma virgula separando o
> > endereço do número, ai fica fácil, mas nem sempre isso é regra, eles
> > usam S/N quando não tem um número..
> >
> > Estou pensando em fazer um split e sair procurando pelos termos mais
> > comuns que eu acho que vai existir no cadastro.. O que vocês acham ??
> >
> > Obrigado,
> > Alessandro
> >
>
> --
> Enviado do meu celular
>
> ________________
> Eldio Santos Junior
> Tel.: (21) 8884-3757
> Skype: eldiojr
> Twitter: @eldius
> Email/GTalk: eldio...@gmail.com <eldiosantos%40gmail.com>
>
>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------