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?
> 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?
> 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?
> 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?
> 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?
> 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;
> 2 - Centralizar o desenvolvimento
Onde? no PostgreSql?
> 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?
> 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?
> 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?
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
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
