Em 29/06/2011 15:35, Fabiano Machado Dias escreveu:
> Não o fato de colocar tudo no "PostgreSQL" e sim o fato de usar
> cursores, offset, sequencias temporárias etc... Desculpe se não fui claro!
Ainda acredito que para a grande maioria das rotinas, e quando digo
grande maioria estou querendo dizer grande maioria mesmo, o uso de
cursores não faz sentido, salvo os casos em que um grande volume de
dados está sendo tratado de uma única vez, o que não me parece ser o caso.
> O fato de você organizar as transações dentro de uma PLs é o mesmo
> exemplo já citado. Ao invés de eu ter um código de baixa de estoque em
> alguma tela, ou procedure em alguma camada intermediária eu tenho uma PL
> que faz isso! É um conjunto de soluções e não apenas o uso de PLs,
> tentei passar uma idéia geral de como fizemos o desenvolvimento.
Achava até hoje que o PostGreSql não permite controle de transações
dentro de uma procedure. Estou desatualizado?? Eu não vi nada na
documentação até hoje.
> O problema é quando um gatilho, dispara um gatilho que dispara outro!!!!
> E as vezes lá no quinto nível aquele quinto gatilho dispara o
> primeiro!!! Daí você tem além um baita problema uma produção parada!
Assim como uma procedure que dispara outra que dispara outra e as vezes
lá no quinto nível ela também pode disparar a primeira. Continuo não
encontrando um motivo técnico substancial que me faça preferir colocar
toda a lógica de negócios dentro do SGDB, aliás, não é só toda a lógica
de negócio, mas também a criação de i/u/d também à cargo do banco de dados.
>>> 3 - Velocidade de desenvolvimento
>> Escrever PL's é mais rápido que escrever código em qualquer outra
>> linguagem?? Como fica o versionamento disso? Como são feitos testes
>> unitários?
>
> Existe diferença? PL/pgSql não é uma linguagem? Talvez você sinta falta
> de uma IDE, é isso? Temos uma IDE pra interface, Windev conhece? No mais
> uso o bom e velho pgadmin!
>
> As versões são controladas por um software que nós mesmos desenvolvemos,
> eu sou um dos responsáveis pelos testes de versão.
Não não é isto, seu tópico foi velocidade de desenvolvimento, e eu
argumentei que escrever código numa PL é o mesmo que escrever código na
sua linguagem favorita. Não vi ganhos de velocidade com a mudança de
linguagem, isto independe de IDE.
>>> 4 - Acesso rápido aos dados pelo cliente
>> Onde PL's ajudam nisto a não ser em casos muito especiais já citados
>> nesta thread diversas vezes?
>
> Já citei um exemplo acima, sem contar a facilidade de poder alterar o
> comportamento do sistema sem ter que interferir no desenvolvimento com
> as PLs customizadas que a PL manutenção procura! Vide palestra.
Acredito que esta complexidade que você criou de uma pl sair procurando
outras pl's customizadas seria mais facilmente definidas e teriam melhor
manutenção se escritas em uma linguagem OO apropriada.
> Não, foi um conjunto de fatores, não existe mágica né! A modelagem
> ajudou a simplificar o desenvolvimento das PLs, as duas coisas andam
> juntas. De nada me adianta ter uma modelagem boa e um framework lento e
> cheio de bugs!
E você não pode estar correndo o risco de atribuir esta melhoria ao
excesso de procedures ao invés da remodelagem?
> Tenho clientes que vão desde atacados até indústria de couros e
> componentes eletrônicos. Nos atacados temos a questão das filiais e
> muita emissão de nota, algo em torno de 8 a 10 mil NFEs por mês, as
> filais são interligadas via VPN, tenho outra que produz 5 a 7 mil peças
> de couro por dia. Isso tudo contabilizando, gerando lote, baixando
> estoque, alimentando pedidos e outros sistemas de apoio.
Ok, já percebi que o volume é muito pequeno.
> Nossos servidores são simples, Xeon Dual ou Quad, discos SAS de 10 e
> 15k, memória entre 4 a 10 gigas!
Servidores superdimensionados para tão pouco, a não ser que seja o
banco de vários clientes rodando em um único servidor.
> Sei lá se tamanho de banco é algo que possa servir de parâmetro mas não
> é muito grande não, já o número de transações é alto.
Tamanho do banco não importa muito mesmo, mas pelos volumes que citou
acho que não devem haver nem transações concorrentes. Um mês teria
aproximadamente 10560 minutos úteis.
> O maior tá perto de 8 giga, que é de um atacado, está rodando desde 2009
> aliás não entendo como as bases de outras sistemas crescem tão rápido!
Fácil, aqui 4 milhões de entregas por mês rastreadas passo a passo,
desde a coleta até a entrega. Gerando rotas para distribuidores com
vários entregadores em todo o país. Cada uma destas entregas com um
identificador único, que é lido através de um leitor de código de barras
cada vez que a entrega muda de status.
> Hoje temos clientes que faturam 3x esse exemplo usando o sistema como um
> todo, mas sei lá, me pergunte algo mais específico.
Uma empresa do tipo fábrica pode fazer 5 notas de um milhão cada uma.
Faturamento não adiciona nada quando estamos falando de banco de dados.
Derrepente, transações por segundo pode ser uma informação mais útil,
mas com o volume que você já citou anteriormente acredito que é um valor
baixo.
>>> Posso te dizer que hoje coloco a cabeça no travesseiro e durmo
>>> tranqüilo! rsrsrs
>> Eu também faço isto sem precisar colocar tudo em procedures.
>
> Ok, generalizar ajuda algo na discussão?
Não ajuda, mas da forma que você colocou deu a entender que você coloca
a cabeça no travesseiro e dorme tranquilo porque colocou tudo para
procedures (que é o objetivo da conversa desta thread) e não porque
desenvolveu um outro ERP do zero.
Suas respostas deram a entender que houve uma mudança na forma de
desenvolvimento do ERP, mas agora vejo que é outro ERP desenvolvido sem
os erros de modelagem do primeiro. Não tem como você sustentar que o
motivo desta "maravilha toda" seja porque você fez procedures para tudo
e colocou toda a regra de negócios no SGDB.
> Talvez, mas fique a vontade para perguntar, se estiver no PGBR esse ano
> fique a vontade também se quiser ver isso tudo na prática.
Não poderei me dar este luxo, infelizmente.
Abraço,
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
