Re: [pgbr-geral] Divisão de módulos do ERP em Esqu emas...
Esqueci de comentar... apesar de usar os esquemas para organizar as coisas eu utilizo a variável search_path para ter a facilidades já citadas de se ter um único esquema... -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] Client encoding
Oi Osvaldo, Obrigado pelas dicas. Vou ver se consigo implementar ainda hoje. Como disse, ainda são testes. Bene Em 01/07/2010 19:53, Osvaldo Kussama escreveu: Em 1 de julho de 2010 19:42, Osvaldo Kussama osvaldo.kuss...@gmail.com escreveu: Em 1 de julho de 2010 11:50, Benedito A. Cruzb...@cria.org.br escreveu: Em 1/7/2010 11:43, Fabrízio de Royes Mello escreveu: Em 1 de julho de 2010 11:29, Benedito A. Cruzb...@cria.org.br escreveu: Porque o mundo não é perfeito... Mesmo o mundo sendo *imperfeito* precisamos tentar nos aproximar da *perfeição*... buscar sempre o melhor... e a colocação do Euler é com esse pensamento... bom, filosofias a parte vamos ao que interessa... Penso que num mundo perfeito eu teria controle sobre todo o processo de desenvolvimento, o que não é o caso. Infelizmente em muitos casos temos que integrar coisas muito diferentes sobre as quais não temos controle na implementação ou configuração. Essa questão de tu ter um cliente com o encoding LATIN [1] e o servidor com UTF-8 [2] tende a ter problemas justamente porque existem diversos caracteres UTF-8 não presentes em LATIN1, então é _natural_ que a conversão não seja bem sucedida. OK. Eu só queria saber se seria possível tratar essa conversão mal sucedida de algum modo. Pelo jeito, não dá. Creio que suas alternativas são: 1) Mudar o encoding do client para UTF-8 2) Mudar o encoding do server para LATIN1 3) Se 1) e 2) não são possíveis então vais ter que criar funções e/ou visões separando o teu modelo físico em que o mesmo faça esse tratamento. Mais alguém tem sugestões para o colega??? [1] http://en.wikipedia.org/wiki/ISO/IEC_8859-1 [2] http://en.wikipedia.org/wiki/UTF-8 -- Fabrízio de Royes Mello Valeu Fabrizio, obrigado pela resposta. Bene Blog sobre TI: http://fabriziomello.blogspot.com Uma possível solução é você identificar no servidor os caracteres não passíveis de conversão UTF-8 - LATIN1 e substituí-lo por, digamos, '?'. Veja uma expressão regular que identifica caracteres não-UTF-8: http://sniptools.com/databases/finding-non-utf8-values-in-postgresql não é o que você precisa mas pode indicar um caminho para a solução. Tente identificar a correspondência de todos os caracteres LATIN1 em UTF-8, creio que o utilitário iconv faça isso, e desenvolva uma expressão regular que capture os caracteres sem correspondência e use a função regexp_replace. Osvaldo Complementando: existe a função convert(string bytea, src_encoding name, dest_encoding name): http://www.postgresql.org/docs/current/interactive/functions-string.html o resultado é um bytea e a conversão utf8_to_iso_8859_1 é uma das existentes. Creio que combinando com a função convert_from(string bytea, src_encoding name), cujo resultado é um text, você consiga resolver seu problema. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Notificação assíncrona
Olá pessoal, alguém sabe o número máximo de caracteres que comporta (ou pode ser utilizado) nos comandos listen e notify? Desde já obrigado. MarceloG! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Notificação assíncrona
Em 2 de julho de 2010 09:48, MarceloG nrhce...@teleon.com.br escreveu: Olá pessoal, alguém sabe o número máximo de caracteres que comporta (ou pode ser utilizado) nos comandos listen e notify? 63 -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] Divisão de módulos do ERP em Es quemas...
Obrigado pela manifestação Mozart, Fabiano e Fabrízio Estive lendo o manual do PostgreSQL na sua versão 8.0.0 no capítulo 5.8 e li alguns motivos que justificam o uso dos esquemas: Existem diversas razões pelas quais pode-se desejar utilizar esquemas: • Para permitir vários usuários utilizarem o mesmo banco de dados sem que um interfira com o outro. • Para organizar objetos do banco de dados em grupos lógicos tornando-os mais gerenciáveis. • Os aplicativos desenvolvidos por terceiros podem ser colocados em esquemas separados, para não haver colisão com nomes de outros objetos. Minha intenção era deixar os módulos separados também com suas respectivas tabelas, mas se terei que escrever mais código, ou tiver que tratar de forma específica em virtude apenas de deixar separados em esquemas, não vejo vantagem em usar este modelo. Olavo Jr. Em 01/07/2010 19:24, Mozart Hasse escreveu: Olá Olavo, A divisão em schemas parece interessante porque realmente divide as tabelas em grupos. À medida que seu modelo cresce (e nem precisa chegar nas 2000 tabelas, com 1000 já se tem problemas), o que costuma aparecer são tabelas compartilhadas por diversos módulos. Não importa em que módulo você as coloque, sempre terá quem interprete que ela deveria estar em outro lugar. Pior ainda quando mudam seus requisitos e começam a sobrar motivos para mudá-la de um módulo para o outro, gerando um retrabalho absurdo por um benefício questionável. Mudar a tabela de lugar em visões de modelo dentro da sua ferramenta de modelagem, contudo, é uma tarefa simples e sem consequências mais sérias, pois você poderá colocar cópias dela em quantos modelos convier. Devido a isso, sou mais favorável a largar mão dessa história de misturar schema com documentação e colocar todas as tabelas num schema só. Facilita enormemente o desenvolvimento e montagem das consultas, além de facilitar *muito* a manutenção. Talvez alguém cogite a idéia de controlar a segurança dos módulos por esquema, porém acho pouco provável que um esquema assim atenda a qualquer cliente por causa das tabelas compartilhadas e potenciais problemas quando uma tabela mudar de módulo. Minha sugestão, portanto, é: use um schema só e seja feliz. Atenciosamente, Mozart Hasse From: C.P.D. - T.I. MoRHenac...@morenarh.com.br To: pgbr-geral@listas.postgresql.org.br Estou desenvolvendo um ERP e vou comercializá-lo em módulos. Em virtude de disponibilizar em módulos, gostaria de separar as tabelas do banco de dados por módulo. Seria adequado o uso de esquema neste caso ? Ou seja no banco de dados teria esquema como: vendas, faturamento, financeiro e para cada esquema suas respectivas tabelas. É uma boa prática usar deste artifício ? ___ 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] Divisão de módulos do ERP em Esqu emas...
Pode haver um esquema geral que tem as tabelas básicas e essenciais, por exemplo. Na maioria das vezes dá pra identificar estas tabelas, os demais se olha caso a caso. Usando junto com o search_path conforme lembrou o Fabrizio, pode ficar bom. Em 1 de julho de 2010 20:24, Mozart Hasse mozart.ha...@usa.net escreveu: Olá Olavo, A divisão em schemas parece interessante porque realmente divide as tabelas em grupos. À medida que seu modelo cresce (e nem precisa chegar nas 2000 tabelas, com 1000 já se tem problemas), o que costuma aparecer são tabelas compartilhadas por diversos módulos. Não importa em que módulo você as coloque, sempre terá quem interprete que ela deveria estar em outro lugar. Pior ainda quando mudam seus requisitos e começam a sobrar motivos para mudá-la de um módulo para o outro, gerando um retrabalho absurdo por um benefício questionável. Mudar a tabela de lugar em visões de modelo dentro da sua ferramenta de modelagem, contudo, é uma tarefa simples e sem consequências mais sérias, pois você poderá colocar cópias dela em quantos modelos convier. Devido a isso, sou mais favorável a largar mão dessa história de misturar schema com documentação e colocar todas as tabelas num schema só. Facilita enormemente o desenvolvimento e montagem das consultas, além de facilitar *muito* a manutenção. Talvez alguém cogite a idéia de controlar a segurança dos módulos por esquema, porém acho pouco provável que um esquema assim atenda a qualquer cliente por causa das tabelas compartilhadas e potenciais problemas quando uma tabela mudar de módulo. Minha sugestão, portanto, é: use um schema só e seja feliz. Atenciosamente, Mozart Hasse From: C.P.D. - T.I. MoRHena c...@morenarh.com.br To: pgbr-geral@listas.postgresql.org.br Estou desenvolvendo um ERP e vou comercializá-lo em módulos. Em virtude de disponibilizar em módulos, gostaria de separar as tabelas do banco de dados por módulo. Seria adequado o uso de esquema neste caso ? Ou seja no banco de dados teria esquema como: vendas, faturamento, financeiro e para cada esquema suas respectivas tabelas. É uma boa prática usar deste artifício ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa Linux User #113925 Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude. -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
