Em 29/06/2011 20:07, Fabiano Machado Dias escreveu:
>>> 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
> Inicia o bloco da transação antes da chamada da PL, chama a PL e encerra
> a transação. Se você usa PL achei que fazia isso.
Eu uso, mas para mim está muito claro que você disse "organizar
transações dentro de uma PL". "Dentro" para mim ainda é diferente de
"fora" como você citou agora. Leia por favor seus dois parágrafos acima,
achei que você tivesse lido.
> A diferença é que você tem o controle, quantas vezes vi gente quebrando
> a cabeça porque só queria alterar um valor numa coluna e o banco travou!
> Travou pq esqueceu ou nem sabia que tinha um gatilho lá fazendo um monte
> de coisa!
Não tem diferença de um gatilho chamando um outro e fazendo um monte de
coisa de uma procedure chamando outras e fazendo um monte de coisa.
Gatilhos nada mais são que chamadas para procedures.
> Você escrever todo um sistema, um framework, as tuas regras de negócio
> em uma ferramenta e ver ele simplesmente morrer é um trauma pra qualquer
> desenvolvedor.
O SGDB também pode morrer. Uma linguagem inteira ou um SGDB inteiro é
menos propenso a morrer do que uma mera ferramenta como o Clarion.
Apostar todas as suas fichas em uma só tecnologia sempre será um risco,
quem faz isto em uma ferramenta somente assume um risco muito maior como
foi seu caso.
Sinto muito pelo seu trauma, o que está fazendo hoje não resolve o
problema da melhor forma, apenas resolve. Tudo poderia ser mais simples,
mais testável e mais garantido que o que você tem hoje, se ser simples e
testável não tem tanto valor assim para você, então está valendo.
> Vou te dar só um exemplo. Você precisa alterar a forma do cálculo do
> custo de todos os insumos de uma ficha técnica. Se a tua regra é na
> aplicação, vai ter que recompilar, gerar uma nova versão, substituir teu
> executável ou coisa similar. Faço isso hoje, mantenho a versão original,
> modifico, atualizo, rodo e não envolvo nenhuma outra parte a aplicação.
Uma pequeno script em uma linguagem tipo o Python não era melhor? Não
envolveria nem a aplicação, nem alteração no banco de dados. Digo isto
porque uso algo deste tipo e uma aplicação minha. O script fica guardado
no banco de dados e pode ser alterado em uma tela do sistema.
Vamos supor que você fez uma alteração na sua procedure de calculo de
custo na empresa A. Ok, um dia você percebe que tem um bug na procedure
de cálculo de custos geral, cria um script para corrigir ela em todos os
seus clientes e bam. Perdeu-se a alteração específica que está naquele
cliente. Ok ok, você pode argumentar que faz isto cliente por cliente
para ser mais personalizado, infelizmente não poderia aceitar isso
porque você também disse que faz as coisas para ser produtivo.
> Os ganhos vão além do código entende? Só um exemplo ok? Existem outros
> casos, mas já tá no fim do dia e estou meio com preguiça pra escrever! rsrs
Eu ainda não os vi. Sinto muito. Todos os ganhos que me citou até agora
sempre trazem consigo uma grande carga de outros problemas. Você não
resolve o problema deste jeito, apenas transfere ele para outro lugar.
> Servidores superdomensionados? No que você roda as suas aplicações?
> Esses servidores são os de mais baixo custo que existem, estão na faixa
> de 4 a 7 mil.
Tenho servidor com mais de 5 anos de idade trabalhando muito bem com
carga bem maior. Mas isto é bem subjetivo e vou parar esta discussão já
que foge do escopo da thread.
> Durmo tranqüilo porque as várias decisões do projeto deram certo.
> Construir do zero e construir errado não adianta nada!
Dar certo não significa que é a melhor coisa a fazer. De qualquer forma
a discussão já deu o que tinha que dar e daqui a pouco vamos entrar no
Paradoxo de Tostines.
>>> 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.
>
> Uma pena, não sei de onde você é, mas se estiver em Porto Alegre pode
> entrar em contato comigo caso seja de seu interesse!
Não poderei me dar ao luxo de ir na PGBR. Mas já tirei todas as
conclusões que precisava à respeito de seu modelo. Pelo menos o
suficiente para continuar não aconselhando.
Qualquer coisa que eu pontue irá mudar na próxima thread. Primeiro foi
a modificação de um ERP que era de um jeito para outro mas o que vimos
na verdade foi a construção de um outro ERP do zero, sem a maioria dos
erros de modelagem do primeiro. Depois as transações que eram dentro das
procedures e rapidamente mudaram para fora como se eu não estivesse lido
claramente o que foi escrito. Está ficando sem graça esta caça ao rato.
Fico por aqui, forte abraço, não haverão mais respostas minhas nesta
thread.
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
