Olá Shander, Suas observações são muito bem vindas.
Quanto a linguagem, não vamos ter o sistema em varias linguagens (mas seria possível um fork dela), vamos ter apenas uma mas "plugins" que podem ser feitos em qualquer linguagem por qualquer pessoa. Creio que não cabe explicar aqui como isto funciona ou o motivo desta decisão, mas é algo que pesou quando surgiu a idéia de colocar a inteligência no banco, pelo menos do que é essencial. Pelas msg vejo que somente o que realmente for essencial e importante, deva ficar em procedures. O restante fica a cargo da aplicação. Bom é isso ai, agradeço as críticas, deu uma boa luz. Em 28 de junho de 2011 18:52, Shander Lyrio <[email protected]>escreveu: > > 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 > -- Att. Udlei Nattis ---------------------------- Nixus Soluções Lojas Virtuais www.nixus.com.br
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
