[python-brasil] django e firebird
Robson Catunda
ou parto pra outro framework?
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
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
marcos thomaz
[]'s
Marcos Thomaz
http://groups.google.com.br/group/django-brasil
________________________________
De: Robson Catunda <catunda...@gmail.com>
>Para: python...@yahoogrupos.com.br
>Enviadas: Terça-feira, 15 de Março de 2011 15:21
>Assunto: [python-brasil] django e firebird
Luciano Ramalho
<catunda...@gmail.com> wrote:
> Tem como trabalhar com django e firebird?
> ou parto pra outro framework?
Eu sugiro partir para outro banco de dados. Ao contrário do Firebird,
o Django está em ascenção.
Há uns dois anos eu e um amigo ajudamos um cliente a migrar um monte
de apps de Delphi com Firebird para Django com PostgreSQL. Deu
trabalho, claro, mas agora o cliente está em uma plataforma que tem um
futuro mais promissor.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
marcos thomaz
[]'s
Marcos Thomaz
>________________________________
>De: Luciano Ramalho <ram...@gmail.com>
>Para: python...@yahoogrupos.com.br
>Cc: Robson Catunda <catunda...@gmail.com>
>Enviadas: Terça-feira, 15 de Março de 2011 16:58
>Assunto: Re: [python-brasil] django e firebird
>
>
>
>On Tue, Mar 15, 2011 at 3:21 PM, Robson Catunda
><catunda...@gmail.com> wrote:
>> Tem como trabalhar com django e firebird?
>> ou parto pra outro framework?
>
>Eu sugiro partir para outro banco de dados. Ao contrário do Firebird,
>o Django está em ascenção.
>
>Há uns dois anos eu e um amigo ajudamos um cliente a migrar um monte
>de apps de Delphi com Firebird para Django com PostgreSQL. Deu
>trabalho, claro, mas agora o cliente está em uma plataforma que tem um
>futuro mais promissor.
>
>--
>Luciano Ramalho
>programador repentista || stand-up programmer
>Twitter: @luciano
>
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
demetrius albuquerque
não conheço tanto o Firebird mas eu também indico a migração para Django com
PostgreSQL, pela maior capacidade do SGBD, não me refiro a capacidade de
armazenamento, mas ao suporte a tunning e outras melhorias que o PostgreSQL
oferecerá a você.
Dá trabalho? Você provavelmente terá bastante trabalho, incialmente perderá
muito tempo se acostumando com as novas funcionalidades do Python/Django e
do PostgreSQL. Sua produtividade provavelmente cairá bastante no inicio. Mas
depois que tiver alguma experiencia com esses dois, logo irá se perguntar
porque não fez essa migração antes.
Atenciosamente,
Demetrius Albuquerque
Linux & SO www.maltzsama.blogspot.com
<http://www.estacaodorock.com>
Em 15 de março de 2011 20:36, marcos thomaz
<marcos...@yahoo.com.br>escreveu:
Shander Lyrio
> Luciano, me permita apenas uma observação no que diz respeito ao banco
> de dados firebird... temos um banco de dados criado no firebird desde
> 2005. Atualmente o banco possui cerca de 2 GB e não nos apresenta
> problema algum. Muito pelo contrário, pela simplicidade de sua
> manutenção, se mostrou muito confiável e estável. Também participei de
> um projeto aqui onde tivemos que fazer a carga de um banco de dados
> Oracle para um Firebird. O banco de dados suporta essa carga (realizada
> mensalmente com todas as ligações de energia do estado) a 4 anos. Tudo
> sem problemas. Mas realmente, se for usar django eu também aconselho a
> usar Postgres.
Eu usei bastante o firebird há muitos anos atrás, tenho muita
experiência neste banco e alguma propriedade para falar dele, mas o
larguei também há muitos anos atrás logo que o banco de dados de meu
cliente principal superou 8GB devido a enormes problemas de performance
e paradas para manutenção (backup/restore para deixar o banco mais leve,
lembra?). Hoje uso o PostGreSql e o banco de dados deste cliente tem 49
GB com manutenção praticamente zero.
O grupo é de Python e normalmente discute-se apenas Python aqui. Se tem
gente parando para sugerir esta mudança de banco de dados, acredite que
a pessoa tem seus motivos. O protocolo de comunicação Client do Firebird
sempre foi um lixo, com excessivas requisições ao banco de dados sem
necessidade, o Firebird 3.0 viria para limpar este protocolo e sabe o
que aconteceu com ele?? Não aconteceu!
Eu guardo todos os meus e-mails enviados desde o ano 2000 e para ter
uma ideia da época exata em que usava o Firebird acabei dando uma
consultada. Lista delphi-br eu ainda defendia o firebird em 2003 até que
ele começou a me deixar na mão, a migração para PostGreSql aconteceu em
2005, na época o Firebird 2.0 chegou cheio de promessas, mas o que vimos
não foi nada do prometido. Depois da migração nunca mais tive dor de
cabeça com relação a banco de dados, acabou backup/restore uma vez por
semana, acabou problemas com collate, acabou corrupção de banco, acabou
lentidão em sistemas remotos devido ao protocolo de comunicação poluído.
Emfim, vou te fazer uma única pequena pergunta em relação ao Firebird
já que o Luciano falou de evolução. Sabe quando iniciou o
desenvolvimento da versão 3 do Firebird com o objetivo de limpar o
protocolo cliente e até hoje não foi concluída? Eu te ajudo a achar a
resposta no RoadMap de 2006 [1] onde estava previsto que a versão final
do Firebird 3.0 codenome Vulcan estaria disponível no 3o trimestre de
2006. Até hoje ele não se tornou realidade. E não se tornou por um só
motivo, limpar o protocolo faria com que os componentes disponíveis por
padrão no Delphi deixassem de funcionar e ninguém queria isso. Zeus DBO?
O mantenedor sumia e aparecia sem deixar rastros e esta suite de
compontens fica mais em fase Alpha do que qualquer coisa, IBO? Quem
queria pagar U$ 195,00 pelos componentes apesar de Cantu pregar aos
quatro ventos que valia cada centavo? Delphi praticamente morreu depois
de vendido pela Borland; com o queda do Delphi, Interbase e Firebird
começaram a cair junto.
Última atualização do driver JDBC para Firebird 2008.
Última atualização do driver .Net para Firebird 2007.
www.comunidade-firebird.org morta desde 2006
Independente da linguagem que se use. O time do Firebird mostrou com o
tempo que não conseguiu evoluir satisfatoriamente o projeto, os mesmos
problemas básicos de 6 anos atrás continuam hoje, exatamente iguais. Ele
apenas continua sendo bem usado porque muitos sistemas comerciais foram
construídos com o Delphi em seus tempos áureos, mas nem de longe é a
melhor opção. Lembro bem que PostGreSql só não era utilizado em
detrimento ao Firebird porque não tinha uma versão nativa para Windows e
precisava rodar sobre o cygwin, mas isto foi resolvido em 2007. Apesar
de que Marcos Cantu ainda prepara um slide em 2010 dizendo que Firebird
é melhor do que PostGreSDql porque o PostGreSql não possui binários para
HP-UX (quem usa este franksteim ainda hoje que você conheça?) e que
requer cygwin para ser compilado no Windows [2], eu quase caí da cadeira
de tanto rir, mas ele vendeu o peixe dele, mesmo que seja mentindo, na
época ele era considerado uma sumidade no Firebird, não sei como está
hoje, mas o povo deve ainda engolir e acreditar em tudo que ele fala sem
questionar. Ainda existe aquela idéia ridícula de que todas as consultas
deveriam ser executadas por Stored Procedures porque o Firebird demorava
para parsear o Sql? Espero que não!
[1] http://is.gd/D2FFfa
[2] http://is.gd/aNKlAQ
Abraço,
--
Shander Lyrio
marcos thomaz
>Eu usei bastante o firebird há muitos anos atrás, tenho muita
>experiência neste banco e alguma propriedade para falar dele, mas o
>larguei também há muitos anos atrás logo que o banco de dados de meu
>cliente principal superou 8GB devido a enormes problemas de performance
>e paradas para manutenção (backup/restore para deixar o banco mais leve,
>lembra?). Hoje uso o PostGreSql e o banco de dados deste cliente tem 49
>GB com manutenção praticamente zero.
Acho que tudo vai da forma com a qual se implementa o banco. Fui verificar o tamanho do banco de dados que citei (da carga do Oracle) ainda não tem o tamanho do banco que você citou (está atualmente com 6 GB), mas com relação a performance, não estou tendo reclamações. Muito pelo contrário. Claro que se você implementou o banco em um único arquivo, teria problemas com certeza. O mesmo ocorre com um banco Postgre onde não se executa o "vacuum" com muita frequencia, e não se configura corretamente o banco.
>O grupo é de Python e normalmente discute-se apenas Python aqui. Se tem
>gente parando para sugerir esta mudança de banco de dados, acredite que
>a pessoa tem seus motivos. O protocolo de comunicação Client do Firebird
>sempre foi um lixo, com excessivas requisições ao banco de dados sem
>necessidade, o Firebird 3.0 viria para limpar este protocolo e sabe o
>que aconteceu com ele?? Não aconteceu!
Tenho mais do que certeza de que o grupo é de Python. E concordo que, se alguém opina, deve ter sua razão. Porém, cada um tem o direito de colocar o seu próprio ponto de vista, isso, se não se transformar em uma flame, se torna até muito produtivo para todos. E realmente, o protocolo de comunicação do Firebird (na internet) realmente é um lixo. Lenta, pesada, e carrega dados desnecessariamente. Em rede local, esse problema nem é possível se dizer que existe. Com relação a requisições excessivas, ainda não tive esse problema. No sistema que citei onde o banco tem 2 GB, teve simultâneamente, mais de 4000 acessos (todos dependendo de consultas relativamente complexas) e não tive problema algum.
>...na época o Firebird 2.0 chegou cheio de promessas, mas o que vimos
>não foi nada do prometido. Depois da migração nunca mais tive dor de
>cabeça com relação a banco de dados, acabou backup/restore uma vez por
>semana, acabou problemas com collate, acabou corrupção de banco, acabou
>lentidão em sistemas remotos devido ao protocolo de comunicação poluído.
Como eu disse, realmente o acesso remoto dele é precário. A história do backup / restore é a mesma do vacuum do postgre. Não é obrigatório, mas é uma manutenção que ajuda. No caso desse banco de 2 GB que tenho (e que não apresenta problemas de performance) faz mais de 2 anos que não faço qualquer tipo de manutenção, a não ser o backup diário (questão de segurança). Claro que não chega aos 49 GB do banco de dados que você tem, mas com a realidade que tenho (banco de no máximo 6GB) está atendendo sem problemas. No caso das requisições remotas (meu sistema foi criado utilizando Delphi 7) substituí a camada de comunicação, trabalhando com Datasnap e o desempenho é excelente. Inclusive, ele possui uma área web (criada com Webbroker), sem uso de cache ou outro, e que teve um desempenho muito melhor do que outras tecnologias que usamos aqui.
> Emfim, vou te fazer uma única pequena pergunta em relação ao Firebird
> já que o Luciano falou de evolução. Sabe quando iniciou o
> desenvolvimento da versão 3 do Firebird com o objetivo de limpar o
> protocolo cliente e até hoje não foi concluída? Eu te ajudo a achar a
> resposta no RoadMap de 2006 [1] onde estava previsto que a versão final
> do Firebird 3.0 codenome Vulcan estaria disponível no 3o trimestre de
> 2006. Até hoje ele não se tornou realidade. E não se tornou por um só
> motivo, limpar o protocolo faria com que os componentes disponíveis por
> padrão no Delphi deixassem de funcionar e ninguém queria isso. Zeus DBO?
Realmente o Vulcan vem sendo apenas uma promessa. Mas, se o componente que você usou é o ZEOS DBO, o problema pode estar aí. Eu utilizei o IBO, específico para Firebird. Sem problemas com conexão, desempenho ou outro. O Zeos por tentar generalizar o acesso, muitas vezes tem um desempenho deplorável, assim como, é péssimo na utilização em conjunto com Datasnap e outras tecnologias. Não estou dizendo que é ruim, só que, na minha opinião, usar o componente específico é (além de mais acertado) muito mais viável.
> O mantenedor sumia e aparecia sem deixar rastros e esta suite de
> compontens fica mais em fase Alpha do que qualquer coisa,
Ele é open-source... ou seja, é (a meu ver) a mesma situação de diversos outros projetos que, se o core team resolver desaparecer, irá sumir... ou não! Porque? se você tem os fontes (que compilam corretamente pois testei) nada impede você de melhorá-lo.
> IBO? Quem
> queria pagar U$ 195,00 pelos componentes apesar de Cantu pregar aos
> quatro ventos que valia cada centavo?
Aqui na empresa foi pago. E realmente valeu cada centavo. Isso é o mesmo que as doações que se faz para projetos free. Se você obtém ganhos com eles, nada mais justo que pagar (ou contribuir).
> Delphi praticamente morreu depois
> de vendido pela Borland; com o queda do Delphi, Interbase e Firebird
> começaram a cair junto.
Desculpe, mas nunca vi um produto que "morreu", lançar atualizações (e versões) anualmente. E na minha humilde opinião, além do delphi, apenas o Visual Studio está no mesmo nível de desenvolvimento de aplicações desktop (a parte pra web a meu ver ainda é ruim). Uma pergunta... se mudar o core team do django por exemplo significa que o projeto vai morrer? Talvez sim, talvez não... vai depender do uso. E, pelo menos na minha região, o uso de Delphi ainda é muito extenso. Está perdendo um pouco do espaço para o Java (e eu , onde posso tente puxar para Python), mas ainda é maioria.
> Última atualização do driver JDBC para Firebird 2008.
> Última atualização do driver .Net para Firebird 2007.
> www.comunidade-firebird.org morta desde 2006
Existe a lista do Cantú. Muito movimentada por sinal. Acho que isso também merece ser citado. Assim como a lista do Bruno Lichot.
JDBC não é usado no delphi, e o .NET, apesar de suportar o Firebird, é desinteressante (a Embarcadero dá mais ênfase ao Interbase).
> Independente da linguagem que se use. O time do Firebird mostrou com o
> tempo que não conseguiu evoluir satisfatoriamente o projeto, os mesmos
> problemas básicos de 6 anos atrás continuam hoje, exatamente iguais.
> Ele
> apenas continua sendo bem usado porque muitos sistemas comerciais foram
> construídos com o Delphi em seus tempos áureos, mas nem de longe é a
> melhor opção.
Depende. Se quem tem não troca, é algo complicado de se dizer. Não estou dizendo que é, nem que não é, apenas estou dizendo que, se te atende com precisão e sem te causar dores de cabeça, ou quaisquer outro problema, é complicado dizer que não é, pelo menos uma boa opção.
>Lembro bem que PostGreSql só não era utilizado em
> detrimento ao Firebird porque não tinha uma versão nativa para Windows e
> precisava rodar sobre o cygwin, mas isto foi resolvido em 2007
Realmente (mas acho que foi em 2006, não lembro bem). Eu mesmo, tenho um sistema que implantei em 2007 usando o postgre e o Delphi. Roda até hoje, em todos os municípios do estado.
> Apesar
> de que Marcos Cantu ainda prepara um slide em 2010 dizendo que Firebird
> é melhor do que PostGreSDql porque o PostGreSql não possui binários para
> HP-UX (quem usa este franksteim ainda hoje que você conheça?) e que
> requer cygwin para ser compilado no Windows [2], eu quase caí da cadeira
> deve tanto rir, mas ele vendeu o peixe dele, mesmo que seja mentindo, na
> época ele era considerado uma sumidade no Firebird, não sei como está
> hoje, mas o povo deve ainda engolir e acreditar em tudo que ele fala sem
> questionar
Acho uma total perda de tempo dizer que esse é melhor que aquele e coisa e tal... é a mesma coisa que briga entre linguagens (python é melhor que ruby... java é melhor que python e blá,blá, blá). No final, cada um defende seu peixe. E realmente, HP-UX é jurássico. E tipo, em todas as comunidades existem pessoas e pessoas. Não procuro ver pelos outros... prefiro tirar minhas próprias conclusões (nota-se pois na minha região, sou um dos poucos que estudam e usam Python. O Marinho esteve conosco aqui a algum tempo atrás e pôde ver isso).
> Ainda existe aquela idéia ridícula de que todas as consultas
> deveriam ser executadas por Stored Procedures porque o Firebird demorava
> para parsear o Sql? Espero que não!
Demorar para parsear o SQL é balela.... conversa mesmo! Eu usava Stored Procedures... não por problemas para parsear o SQL, mas quando a consulta se tornava muito extensa ou complexa, e eu notava que, usando índices em campos corretos, eu obteria ganhos de performance nas consultas. E, Stored Procedures, são muuuito mais complicadas no Postgre. Basta uma pequena consulta pela internet; Se você precisar de dados específicos, tem que criar um type, e depois usá-lo como retorno da SP.
Bem, não é minha intenção (nem nunca foi) criar um discussão totalmente off. Apenas expus minha opinião, mediante o que trabalhei, vi e vejo. Até porque hoje, 70% de meus projetos envolvem python (em especial, no desenvolvimento de aplicações web usando django). E como o assunto se tornou totalmente OFF, acho que nem cabe mais a discussão.
[]'s
Marcos Thomaz
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Eduardo Cereto Carvalho
implementação sim que deve ser baixada separadamente e instalada.
http://code.google.com/p/django-firebird/
Outra opção que você tem é utilizar o django sem utilizar a parte de ORM.
Apenas se beneficiando de sua arquitetura e outros módulos e fazendo as
queries direto em SQL. Claro que fazendo assim você está deixando de usar
uma das partes mais importantes do django e provavelmente não conseguirá
aplicações de terceiros incluindo o admin. Mas entre isso e ir para outro
framework eu acho que da na mesma.
2011/3/15 demetrius albuquerque <cau...@gmail.com>
--
Eduardo Cereto Carvalho
Shander
> arquivo, teria problemas com certeza. O mesmo ocorre com um banco
> configura corretamente o banco.
Isto não é mais assim no PostGreSql há muito tempo.
> excessivas, ainda não tive esse problema. No sistema que citei onde o
> banco tem 2 GB, teve simultâneamente, mais de 4000 acessos (todos
> dependendo de consultas relativamente complexas) e não tive problema algum.
Este número está extremamente maior do que eu poderia acreditar que se
consiga com um banco firebird, acho difÃcil imaginar até com o
PostGreSql apesar de saber que existem casos, mas infelizmente jamais
conseguirei aceitá-lo como real até ver com meus próprios olhos. Sinto
muito. Claro que estou considerando simultâneos como simultâneos mesmo,
não estou pensando em 4000 usuários, mas 4000 consultas sendo executadas
no mesmo instante por 4000 usuários conectados no mesmo banco de dados.
O banco de dados do meu maior cliente tem quase 3000 usuários, mas
nunca houve caso de mais de 100 acessos ao banco de dados "simultâneos",
98 foi o máximo para ser mais exato.
Poderia citar outros motivos, como o caso de a maior parte dos sistemas
operacionais somente suportar 1024 conexões por porta TCP/IP (este é
inclusive o limite definido no Firebird Super Classic [2]), mas é claro
que eu posso estar desatualizado em relação a isto. O Twitter tem uma
média de 456 Tweetes por segundo (consultas extremamente simples) e
chegou ao máximo de 6939 [3], mas aà já estamos de banco de dados não
relacional e distribuÃdo em centenas de servidores e ainda consultas
extremamente simples. Tem muito mais coisa, mas se eu continuar vai
fugir completamente do escopo da discussão que é Evolução do Firebird.
> Desculpe, mas nunca vi um produto que "morreu", lançar atualizações (e
> versões) anualmente. E na minha humilde opinião, além do delphi, apenas
A Embarcadero não lança atualizações. Lança novas versões para que você
tenha que pagar pelo produto novamente. E a cada nova versão não se
corrigem os erros da versão anterior. Isto é fato que não se tem como
refutar.
> morrer? Talvez sim, talvez não... vai depender do uso. E, pelo menos na
> minha região, o uso de Delphi ainda é muito extenso. Está perdendo um
> pouco do espaço para o Java (e eu , onde posso tente puxar para Python),
> mas ainda é maioria.
É extenso porque ninguém quer pagar o preço de migrar algo que já
existe e está funcionando. Cobol ainda existe por causa disso. Lembre-se
que nossa conversa é sobre a evolução. Se não existe a preocupação de
evolução do programa não tem porque mudar do Delphi ou do Firebird, eles
funcionam, e funcionam bem, funcionaram para mim, só que estão evoluindo
na velocidade de uma carroça.
> Existe a lista do Cantú. Muito movimentada por sinal. Acho que isso
> também merece ser citado. Assim como a lista do Bruno Lichot.
> JDBC não é usado no delphi, e o .NET, apesar de suportar o Firebird, é
> desinteressante (a Embarcadero dá mais ênfase ao Interbase).
Mas uma vez mudou o foco. Estamos falando que o Firebird não está
evoluindo, e para mim um banco de dados que não tem drivers atualizados
para as duas tecnologias mais usadas para desenvolvimento de software em
todo o mundo não pode ser levado a sério. Não estou dizendo que são as
melhores tecnologias, apenas que são as mais usadas.
> Depende. Se quem tem não troca, é algo complicado de se dizer. Não estou
> dizendo que é, nem que não é, apenas estou dizendo que, se te atende com
> precisão e sem te causar dores de cabeça, ou quaisquer outro problema, é
> complicado dizer que não é, pelo menos uma boa opção.
Entendo, mais uma vez a mesma mudança de foco. Estamos falando de
evolução, não de manutenção, não dá dor de cabeça porque não evolui.
Quer algo mais barato e cômodo do que trabalhar com uma tecnologia que
mantem a mesma versão sem evolução, sem melhorias e por conseguinte sem
riscos, por diversos anos?
> consultas. E, Stored Procedures, são muuuito mais complicadas no
> Postgre. Basta uma pequena consulta pela internet; Se você precisar de
> dados especÃficos, tem que criar um type, e depois usá-lo como retorno
> da SP.
Apesar do que, você pode escrever em PostGreSql stored procedures em
diferentes linguagens, inclusive em python como eu faço. O que você acha
ruim no PostGreSql é exatamente uma das coisas que eu acho mais acertado
e é a primeira dificuldade de quem vem do Firebird para o PostGreSql
porque foi doutrinado que Stored Procedures devem ser usadas para
retornar múltiplas tuplas por causa da velocidade.
De qualquer forma, acho que aqui conseguiremos fechar o assunto, porque
ao contrário do Firebird que não evolui e é sempre a mesma coisa o
PostGreSql evolui e melhora a todo o tempo. Eu não sei quando você
testou isto no PostGreSql, mas já faz muito tempo que isto aqui [1]
funciona sem você precisar criar um type:
teste com:
select * from funcao_teste(2);
select * from funcao_teste(3);
Acho que é isto que o Luciano quiz dizer. A única questão aqui
discutida deveria ser a evolução. Ninguém disse que o Firebird não tem
seu uso, eu comprei um sistema de finanças pessoais que utiliza o
Firebird, o sistema é ótimo, certamente foi feito em Delphi e nunca tive
problema com o banco de dados.
[1] http://pastebin.com/5SSeYYU5
[2] http://bit.ly/h0yI41
[3] http://bit.ly/fL9qNb
--
Shander Lyrio
------------------------------------
Python-Brasil
http://www.python.org.br/wiki/AntesDePerguntar
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
Jonas Andrade
MySQL ou Postgresql
[]'s
-jonas
Fellipe Henrique
Apenas pra entrar de "bicão" na thread, mas sem mudar do assunto por si
só...
Hoje tenho um sistema feito em Delphi-Firebird, e estou procurando
tecnologia pra partir pra Web.. passar o sistema inteiro pra Web.. estou
muito interessado e tendendo para o lado do Python, mas eis que entra uma
questão que como iniciante procurei e até agora não achei resposta boa..
- Compensa mudar pra Python?
- O que indicam pra utilizar, qual Framework? Procurei saber e me falaram do
Django... ele me atenderia?
- Existe framework para Python, onde se pode fazer relatórios, imprimir em
PDF, gráficos, utilizar certificado digital (para emissão de NF-e), mas
importante.. pode-se utilizar certificado A-3 ?
- O sistema será desenvolvido em máquina Windows, porém o servidor será
Linux, algum problema nesse aspecto?
- Como o desenvolvimento é em Windows, o que indicam pra programar, qual
IDE?
- O python possui um sistema de Debug parecido com o do Delphi?
Me desculpe se fugiu do tema, mas essas questões estão batendo na minha
cabeça e até agora não encontrei respostas...
Att.
--
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de Softwares for Win32
Linux Administrator
Luciano Ramalho
> Apenas pra entrar de "bicão" na thread, mas sem mudar do assunto por si
> só...
>
> Hoje tenho um sistema feito em Delphi-Firebird, e estou procurando
> tecnologia pra partir pra Web.. passar o sistema inteiro pra Web.. estou
> muito interessado e tendendo para o lado do Python, mas eis que entra uma
> questão que como iniciante procurei e até agora não achei resposta boa..
>
> - Compensa mudar pra Python?
> - O que indicam pra utilizar, qual Framework? Procurei saber e me falaram do
> Django... ele me atenderia?
> - Existe framework para Python, onde se pode fazer relatórios, imprimir em
> PDF, gráficos, utilizar certificado digital (para emissão de NF-e), mas
> importante.. pode-se utilizar certificado A-3 ?
> - O sistema será desenvolvido em máquina Windows, porém o servidor será
> Linux, algum problema nesse aspecto?
> - Como o desenvolvimento é em Windows, o que indicam pra programar, qual
> IDE?
> - O python possui um sistema de Debug parecido com o do Delphi?
>
> Me desculpe se fugiu do tema, mas essas questões estão batendo na minha
> cabeça e até agora não encontrei respostas...
Falipe, seja bem vindo.
Perdão pela franqueza mas todas as suas questões já foram
exaustivamente discutidas e respondidas nesta lista de discussão,
então certamente você não encontrou porque foi procurar no lugar
errado. Experimente copiar e colar suas perguntas no Google.
Quando tiver perguntas que o Google não consegue responder, manda pra
cá que tem muita gente boa super disposta a ajudar, OK?
Boa sorte!
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Leonardo Santagada
> Hoje tenho um sistema feito em Delphi-Firebird, e estou procurando
> tecnologia pra partir pra Web.. passar o sistema inteiro pra Web.. estou
> muito interessado e tendendo para o lado do Python, mas eis que entra uma
> questão que como iniciante procurei e até agora não achei resposta boa..
>
> - Compensa mudar pra Python?
> - O que indicam pra utilizar, qual Framework? Procurei saber e me falaram do
> Django... ele me atenderia?
Com certeza.
> - Existe framework para Python, onde se pode fazer relatórios, imprimir em
> PDF, gráficos, utilizar certificado digital (para emissão de NF-e), mas
> importante.. pode-se utilizar certificado A-3 ?
Sim, sim, sim, sim, não sei mas provavelmente sim
> - O sistema será desenvolvido em máquina Windows, porém o servidor será
> Linux, algum problema nesse aspecto?
Não, nenhum. Se tu abandonar o firebird então é só felicidade.
> - Como o desenvolvimento é em Windows, o que indicam pra programar, qual
> IDE?
Qualquer editor de texto que tu quiser, se tu gosta da complicação do
delphi winide, pycharm ou pydev+eclipse são o que tu esta procurando
> - O python possui um sistema de Debug parecido com o do Delphi?
Sim
--
Leonardo Santagada
Fellipe Henrique
Já iniciarei os estudos...
[]s
Fellipe H.
--
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de Softwares for Win32
Linux Administrator
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
marcos thomaz
[]'s
Marcos Thomaz
>________________________________
>De: Shander Lyrio <sha...@nucleo45.com.br>
>Para: python...@yahoogrupos.com.br
>Enviadas: Quarta-feira, 16 de Março de 2011 1:00
>Assunto: Re: [python-brasil] django e firebird (off-topic firebird x postgresql)
>
>
>
>Em 15-03-2011 21:36, marcos thomaz escreveu:
>> Luciano, me permita apenas uma observação no que diz respeito ao banco
>> de dados firebird... temos um banco de dados criado no firebird desde
>> 2005. Atualmente o banco possui cerca de 2 GB e não nos apresenta
>> problema algum. Muito pelo contrário, pela simplicidade de sua
>> manutenção, se mostrou muito confiável e estável. Também participei de
>> um projeto aqui onde tivemos que fazer a carga de um banco de dados
>> Oracle para um Firebird. O banco de dados suporta essa carga (realizada
>> mensalmente com todas as ligações de energia do estado) a 4 anos. Tudo
>> sem problemas. Mas realmente, se for usar django eu também aconselho a
>> usar Postgres.
>
>Eu usei bastante o firebird há muitos anos atrás, tenho muita
>experiência neste banco e alguma propriedade para falar dele, mas o
>larguei também há muitos anos atrás logo que o banco de dados de meu
>cliente principal superou 8GB devido a enormes problemas de performance
>e paradas para manutenção (backup/restore para deixar o banco mais leve,
>lembra?). Hoje uso o PostGreSql e o banco de dados deste cliente tem 49
>GB com manutenção praticamente zero.
>
>O grupo é de Python e normalmente discute-se apenas Python aqui. Se tem
>gente parando para sugerir esta mudança de banco de dados, acredite que
>a pessoa tem seus motivos. O protocolo de comunicação Client do Firebird
>sempre foi um lixo, com excessivas requisições ao banco de dados sem
>necessidade, o Firebird 3.0 viria para limpar este protocolo e sabe o
>que aconteceu com ele?? Não aconteceu!
>
>Eu guardo todos os meus e-mails enviados desde o ano 2000 e para ter
>uma ideia da época exata em que usava o Firebird acabei dando uma
>consultada. Lista delphi-br eu ainda defendia o firebird em 2003 até que
>ele começou a me deixar na mão, a migração para PostGreSql aconteceu em
>2005, na época o Firebird 2.0 chegou cheio de promessas, mas o que vimos
>não foi nada do prometido. Depois da migração nunca mais tive dor de
>cabeça com relação a banco de dados, acabou backup/restore uma vez por
>semana, acabou problemas com collate, acabou corrupção de banco, acabou
>lentidão em sistemas remotos devido ao protocolo de comunicação poluído.
>
>Emfim, vou te fazer uma única pequena pergunta em relação ao Firebird
>já que o Luciano falou de evolução. Sabe quando iniciou o
>desenvolvimento da versão 3 do Firebird com o objetivo de limpar o
>protocolo cliente e até hoje não foi concluída? Eu te ajudo a achar a
>resposta no RoadMap de 2006 [1] onde estava previsto que a versão final
>do Firebird 3.0 codenome Vulcan estaria disponível no 3o trimestre de
>2006. Até hoje ele não se tornou realidade. E não se tornou por um só
>motivo, limpar o protocolo faria com que os componentes disponíveis por
>padrão no Delphi deixassem de funcionar e ninguém queria isso. Zeus DBO?
>O mantenedor sumia e aparecia sem deixar rastros e esta suite de
>compontens fica mais em fase Alpha do que qualquer coisa, IBO? Quem
>queria pagar U$ 195,00 pelos componentes apesar de Cantu pregar aos
>quatro ventos que valia cada centavo? Delphi praticamente morreu depois
>de vendido pela Borland; com o queda do Delphi, Interbase e Firebird
>começaram a cair junto.
>
>Última atualização do driver JDBC para Firebird 2008.
>Última atualização do driver .Net para Firebird 2007.
>www.comunidade-firebird.org morta desde 2006
>
>Independente da linguagem que se use. O time do Firebird mostrou com o
>tempo que não conseguiu evoluir satisfatoriamente o projeto, os mesmos
>problemas básicos de 6 anos atrás continuam hoje, exatamente iguais. Ele
>apenas continua sendo bem usado porque muitos sistemas comerciais foram
>construídos com o Delphi em seus tempos áureos, mas nem de longe é a
>melhor opção. Lembro bem que PostGreSql só não era utilizado em
>detrimento ao Firebird porque não tinha uma versão nativa para Windows e
>precisava rodar sobre o cygwin, mas isto foi resolvido em 2007. Apesar
>de que Marcos Cantu ainda prepara um slide em 2010 dizendo que Firebird
>é melhor do que PostGreSDql porque o PostGreSql não possui binários para
>HP-UX (quem usa este franksteim ainda hoje que você conheça?) e que
>requer cygwin para ser compilado no Windows [2], eu quase caí da cadeira
>de tanto rir, mas ele vendeu o peixe dele, mesmo que seja mentindo, na
>época ele era considerado uma sumidade no Firebird, não sei como está
>hoje, mas o povo deve ainda engolir e acreditar em tudo que ele fala sem
>questionar. Ainda existe aquela idéia ridícula de que todas as consultas
>deveriam ser executadas por Stored Procedures porque o Firebird demorava
>para parsear o Sql? Espero que não!
>
>[1] http://is.gd/D2FFfa
>[2] http://is.gd/aNKlAQ
>
>Abraço,
>
>--
>Shander Lyrio
>
>
>
>
Shander
Em 16/03/2011 14:53, marcos thomaz escreveu:
> Realmente, acho que o assunto fugiu demais da discussão original e, se
> formos expor e discutir "o sexo dos anjos" aqui, vai se tornar uma
> discussão longa, chata e totalmente fora do contexto. Diversas
> colocações minhas, não se fizeram por entender, mas acho que não cabe
> prolongarmos ainda mais a discussão (até porque é uma lista de python,
> não de banco de dados ou outro - apesar de ter relevância).
Eu estou super disposto a conversar contigo em private se você quiser.
Lembrando que o assunto é evolução do Firebird que não acompanha a
evolução do django. E não se o Firebird é bom ou ruim, confiável ou não,
isto sim seria discutir o sexo dos anjos.
Abraço,
--
Shander Lyrio
marcos thomaz
[]'s
Marcos Thomaz
>________________________________
>De: Shander <sha...@nucleo45.com.br>
>Para: python...@yahoogrupos.com.br
>Enviadas: Quarta-feira, 16 de Março de 2011 15:04
>Assunto: Re: [python-brasil] django e firebird (off-topic firebird x postgresql)
>
>
>
>
>Em 16/03/2011 14:53, marcos thomaz escreveu:
>> Realmente, acho que o assunto fugiu demais da discussão original e, se
>> formos expor e discutir "o sexo dos anjos" aqui, vai se tornar uma
>> discussão longa, chata e totalmente fora do contexto. Diversas
>> colocações minhas, não se fizeram por entender, mas acho que não cabe
>> prolongarmos ainda mais a discussão (até porque é uma lista de python,
>> não de banco de dados ou outro - apesar de ter relevância).
>
>Eu estou super disposto a conversar contigo em private se você quiser.
>Lembrando que o assunto é evolução do Firebird que não acompanha a
>evolução do django. E não se o Firebird é bom ou ruim, confiável ou não,
>isto sim seria discutir o sexo dos anjos.
>
>Abraço,
>
>--
>Shander Lyrio
>
>
>
>
[As partes desta mensagem que não continham texto foram removidas]
------------------------------------
Robson Catunda
Por favor, eu apenas quis saber da possibilidade de acessar o firebird via
django, devido ao fato de sempre ter utilizado o interbase e depois firebird
em meus sistemas delphi desde 1999 e pretendia mante-lo agora que estou
começando a ver python.
Tenho consciencia de que o firebird não é o banco mais adequado pra
trabalhar em internet, que para esse caso os mais utiizados sempre foram
mysql, sqlserver, postgree e oracle.
Minha relutancia em tal mudança é apenas pela afinidade existente e
conhecimento do firebird, mas sendo necessário, não vejo problema em mudar
pra postgree que é tão bom e GRATUITO quanto o firebird, apresentando uma
melhora no protocolo de comunicação na internet, além de que a curva de
aprendizado pra passar de um pro outro é pequena.
Agradeço as opiniões de cada um de vcs, mas GUARDEM AS ARMAS ..... PAZ E
AMOR......
Valews........
Leonardo Santagada
> Minha relutancia em tal mudança é apenas pela afinidade existente e
> conhecimento do firebird, mas sendo necessário, não vejo problema em mudar
> pra postgree que é tão bom e GRATUITO quanto o firebird, apresentando uma
> melhora no protocolo de comunicação na internet, além de que a curva de
> aprendizado pra passar de um pro outro é pequena.
Não o postgresql não é tão bom quanto o firebird, ele é ordens de
magnitude melhor que o firebird. Eu digo isso em termos de features,
suporte, comunidade, documentação, protocolo de comunicação,
segurança, performance, futuro, compatibilidade, etc. O MySQL é bem
legal também e na versão 5 tem todas as features que eu já precisei
num banco, só é um pouco mais chato de configurar e a vantagem é que o
sistema de replicação dele existe a bem mais tempo e já provou que
escala muito bem.
--
Leonardo Santagada