Em 29/6/2011 14:06, Shander Lyrio escreveu: > Em 29/06/2011 12:54, Fabiano Machado Dias escreveu: >> Sim, temos uma PL que controla os comandos DML, ou seja, a interface >> passa os campos e ela se encarrega do resto. > Sério?
Sim, desenvolvemos o nosso próprio framework rsrs! Ela não faz só isso, além de escrever e controlar os comandos tem mais coisas que são controladas pela PL manutenção! >> Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem >> perder a performance que tínhamos em outra linguagem, performance de >> telas, acesso rápido via cursores etc. > Você está dizendo que colocar tudo no PostGreSql tornou suas telas mais > rápidas?? O que uma coisa tem haver com a outra? 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! >> Tudo deveria ter controle relacional, colocamos todas as restrições no >> banco e começamos a desenvolver as PLs básicas. > O que tem haver "controle relacional" com "lógica de negócio em > procedures para tudo" dentro do banco de dados? Conheço vários ERPs onde as restrições ficam na interface! Já vi bancos onde não existia uma constraint sequer, outros que só tinham 2 tipos de dados!!! 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. >> Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de >> dados não era no banco, vi vários problemas de transação ocorrendo, sem > Como assim a camada de dados não era o banco? Usava o PostGreSql para > que então? Era um sistema em 3 camadas, me referi mal, quis dizer que a camada de negócio não era no banco, existiam PLs que faziam alguns processos, mas a grande maioria era resolvida na camada intermediária e só gravava no banco. >> contar os problemas com gatilhos e a lentidão, então resolvemos que os >> processos seriam implementados totalmente dentro das PLs. > Resolveram assim do nada, sem tentar descobrir o real problema? Sim, descobrimos o problema, mas o sistema não era nosso e quando vimos o que o uso de gatilhos poderia causar tomamos a decisão e fazer diferente no nosso sistema. 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! >> O que queríamos era: >> >> 1 - Segurança nas transações, > Isso não tem nada haver com tudo feito por PL's dentro do banco de > dados. O Postgresql te garante isto de forma totalmente independente de > pl's; Sim, mas definimos que seria regra. >> 2 - Centralizar o desenvolvimento > Onde? no PostgreSql? Sim, nas PLs. >> 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. >> 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. >> Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a >> tão falada chave artificial para as PKs e fizemos as restrições devidas >> nas chaves naturais (UKs), assim conseguimos resolver os problemas do >> modelo físico e do lógico, claro que eles se misturam (não chegam ao >> usuário mas ao programador sim), mas pra nós não é problema, aliás nunca >> foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha >> resposta a pergunta do colega!) > Mas não respondeu, aliás, estou muito mais confuso agora. O que tem > haver a modelagem com o uso extensivo de PL's? Será que o problema > inicial já não era a modelagem e você está achando que seus ganhos foram > com o excesso de PL's mas na verdade foi com a mudança radical da modelagem? 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! >> Depois de trabalhar com tabelas em que a PK era composta por 16 campos e > Acredito firmemente que você está confundindo uma restrição unique com > PK. Acho que é limitação do meu cérebro mas não consigo sequer imaginar > uma entidade que precise de 16 campos para indicar sua unicidade. > Acredito agora, ainda mais firmemente, que seu problema era de modelagem > e não regras de negócio dentro ou fora do banco de dados. Não fui eu que confundi! Foram os programadores e DBAs do projeto que trabalhei anteriormente. Aliás quem questionasse isso era repreendido na hora!!! rsrsrs Também não me passa na cabeça isso, mas acredite existe muito pacote assim no mercado! >> tinha que juntar mais mais outras 20 tabelas, abolimos as PKs >> compostas, isso me deu um ganho de performance bom e uma escrita rápida >> também, a criação de índices também ficou fácil. > Aboliu pk composta que não deveria ser pk composta. Mas uma vez acho > que seu ganho foi a mudança de modelagem e nada teve haver com "toda" a > lógica de negócios dentro do PostgreSql. Já respondi acima, é um conjunto de fatores! >> PLs que controlam a auditoria de outras PLs etc. > Tem também um sistema difícil de se testar, difícil de versionar, > difícil de encontrar gargalos de performance. Mas isto certamente > funciona para sistema com pouco volume de dados. Na verdade é super simples, e hoje não tenho nenhum gargalo, justamente pela forma de desenvolvimento que foi mostrada é fácil de achar eles antes de se tornarem críticos. Quanto ao volume de dados, bom, não tenho algo monstro do como um sistema em ambiente nacional. 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. Nossos servidores são simples, Xeon Dual ou Quad, discos SAS de 10 e 15k, memória entre 4 a 10 gigas! 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. 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! >> Fizemos um uso muito restrito de gatilhos, dá pra contar nos dedos >> quantos tem no sistema, afinal tenho o controle do que acontece nas PLs! > Qual controle diferente tem em procedures que não poderia ter nos > gatilhos. Os gatilhos nada mais são do que o chamado a procedures. A PL eu sei quando é disparada, e se precisar que posso criar controles onde uma chama a outro! Já citei um caso dos gatilhos acima! >> Bom, poderia te dar vários exemplos, dá uma olhada na palestra do pgcon >> de 2009, lá tem casos mais específicos do que fizemos. > Eu dei, inclusive diversas críticas técnicas ao que foi exposto e a > resposta foi algo como "está rodando no cliente com faturamento de 5 > milhões mensais" sem nenhuma explicação técnica que justificasse a > escolha. O fato de estar rodando em um cliente deste porte não indica > que esta é uma boa opção. No máximo, que vocês estão conseguindo manter > o cliente feliz ou que ele ficou tão preso que não consegue mais mudar e > eu não pretendo entrar no mérito desta questão. Se você não tem > explicação técnica para esta decisão, para mim ela não vale como boa > solução. O tempo que tivemos pra responder era pequeno, mas que tipo de informações você precisa? Se for algo que possa revelar te respondo sem problemas. Hoje temos clientes que faturam 3x esse exemplo usando o sistema como um todo, mas sei lá, me pergunte algo mais específico. >> 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? >> Nunca mais me preocupei com corrupções, dados inconsistentes, banco >> travando etc!!! > A sua falta de preocupação, dentro do que li foi pela correção do > modelo de dados e não por colocar tudo em procedures, ou eu posso não > ter entendido nada do que você escreveu. 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. Abração, Fabiano Machado Dias > Abraço, > > -- > Shander Lyrio > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
