Em 29/6/2011 17:38, Shander Lyrio escreveu: > 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.
Cursores foi um exemplo, uso eles para paginação no browse de tela ou em algum relatório específico. >> 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. 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. >> 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. 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! Se você esteve na apresentação talvez tenha esquecido que o principal motivo de colocar a regra no banco foi para não ter que ficar dependente de nenhuma linguagem, tivemos uma experiência com o Clarion que não gostaria que acontecesse com ninguém. 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. Eu tinha uma opinião parecida até com a sua, mas mudei depois disso. Hoje troco de linguagem em poucos meses sem muito trabalho, claro estou preso ao elefante, mas isso não me assusta nenhum pouco. Pelo contrário. >>>> 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. 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. 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 >>>> 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 sei, mas respeito a sua opinião e minha é diferente. >> 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. 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. Não sei que tipo de cliente você trabalha, mas isso pra mim é o básico que uma empresa precisa ter. Até não pela velocidade e sim pela confiabilidade, não vai me dizer que sua aplicação roda em uma máquina montada né? Se tiver uma configuração de servidor que seja diferente disso me mande ok? Eu mesmo quero comprar um pra mim, porque hoje no mercado não conheço algo muito abaixo disso! Quando fechamos um cliente eu tenho uma configuração bem básica, que é +- assim. 2 Discos SAS de 15 k (Para fazer no mínimo Raid 1) Memória mínima de 4 GB (Por favor né, tá mais barato do que nunca) Processador Intel (No mínimo um dual core, tem algo diferente no mercado?) Placa de rede 1000 mbps. O que q tem de superdimensionado aqui? Um site que dá pra tirar uma idéia mínima http://www.dell.com/br/empresa/p/servers >> 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. Por favor me mande a fórmula que você usou pra chegar nesse número rsrsrs! Agora fiquei curioso. Transações concorrentes é o chão de um sistema ERP! >> 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. Ok, mas não é muito diferente de uma linha de produção com multiplos subconjuntos, e múltiplas fichas técnicas com vários subníveis. Aliás no meu sistema é possível definir quantos níveis precisar, conheço ERP de NOME que limita até 3 ou 5 níveis. Produto 1 que precisa do Produto 2 que precisa do 3 e por aí vai... >> 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. Sim, eu sei, mas os controles que um empresa desse porte precisa, desde o contábil e fiscal até o gasto de papel por setor não é o mesmo da padaria da esquina rsrs! As transações eu posso fazer um levantamento se for de seu interesse, mas te digo que não é algo pequeno para se desconsiderar e nem grande para ser preocupante, a maioria dos clientes é empresa de médio-grande porte. Não é uma Coca-Cola ou GM da vida! >>>> 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. Durmo tranqüilo porque as várias decisões do projeto deram certo. Construir do zero e construir errado não adianta nada! > 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. Uma pena, não sei de onde você é, mas se estiver em Porto Alegre pode entrar em contato comigo caso seja de seu interesse! fabi...@wolaksistemas.com.br fabi...@erpws.com.br Abração, Fabiano Machado Dias > Abraço, > > -- > Shander Lyrio > _______________________________________________ > 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
