Em 28/06/2011 17:51, Udlei Nattis escreveu:
> A lógica de nosso sistema é bastante complexa e teremos uma série de
> programadores trabalhando em cima dele em diversos pontos. Imagina então
> quando o código for liberado... muitas pessoas vão trabalhar em cima
> dele simultaneamente o que aumenta a possibilidade de erros.
Mais uma vez reforço. Isto se garante com testes unitários, funcionais
e de integração. Ainda mais se vai abrir o código, pois como alguém
poderá adicionar plugins para melhorar o sistema? Como seria um plugin
se tudo roda dentro do banco de dados? Se um usuário quiser mudar algo
no sistema, tipo, eu quero que o log seja feito de outra forma, eu quero
melhorar a performance usando memcached, não vai dar porque é tudo feito
dentro de uma única mega power procedure.
<opiniaopessoal flames="off">
A regra geral, é que as empresas não tem problemas em ter vários
sistemas em diversas linguagens, mas é muito mais complicado a empresa
ter vários servidores de banco de dados, porque vai precisar de um DBA
com conhecimento em PostGreSql, outro para Sql Server, outro para
Oracle, etc... Quem já tem um servidor de banco de dados, não vai querer
dividir estes recursos com outro banco de dados que não é o normalmente
usado na empresa.
</opiniaopessoal>
> Vamos a um exemplo, quando um pedido é feito, temos que registra-lo em
> diversas tabelas:
>
> tb_pedido, tb_pedido_item, tb_pedido_pagamentos
É para isto que temos um recurso chamado transação, que dependendo de
como você utilizava o Mysql você não tinha antes.
> Além de baixar estoque, criar movimentacao do estoque, criar log do
> usuario, gerar estatistica fixa entre outras ações.
Isto não é responsabilidade do banco de dados e sim da aplicação. Você
vai engessar o crescimento de sua aplicação. E se o cliente A quiser que
o controle de estoque seja integrado com o dele, e se quiser as
estatísticas de outra forma diferente do cliente A. Isto é relativamente
fácil se está implementado em alguma linguagem OO e seguindo boas
práticas, mas não vejo como poderia ser feito se estivesse embutido no
banco de dados.
> É muito mais conveniente neste caso ter uma procedure que faça tudo isso
> com um simples criar_pedido("dados") do que ter que criar funções em
> diversas linguagens e permitir uma margem de erro muito maior.
Apesar de eu não ter conhecimento de qualquer sistema em que você possa
escolher ele feito em PHP, Python, Java. Acho extremamente improvável
algo como: "Ei cliente, olhe, temos o e-commerce X, você pode escolher a
linguagem em que ele é feito PHP, Python ou Java porque nós
implementamos ele nas 3 linguagens, mas você não pode escolher o banco
de dados."
"Fazer tudo isto com segurança" deveria ser traduzido para "Fazer tudo
isto dentro de um contexto transacional para garantir a integridade dos
dados". Você não vai ter mais segurança jogando toda a responsabilidade
para o banco de dados porque o cara que programa a procedure pode errar
lá também. Segurança que nada vai sair errado é com testes unitários,
funcionais, de integração e outros se existirem.
> Não vejo como isto pode engessar o banco.
Espere algum dia um cliente com bastante dinheiro para investir, que
tem um banco de dados Sql Server e quiser que o banco de dados utilizado
pela solução seja Sql Server, depois tente migrar suas procedures e
mantê-las entre 2 bancos de dados.
Se você pergunta para milhares de usuários da lista se alguém tem
alguma experiência neste assunto, você deveria aceitar as experiências
que estes usuários tem e não simplesmente rechaçá-las porque não está de
acordo com o que você pensa ou quer. Se você quer algo apenas para
apoiar sua ideia, já lhe adianto que não vai ser algo muito fácil de
conseguir, porque eu conheço bastante gente que foi por este caminho e
teve problemas na hora de voltar.
Boa sorte,
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
