On 1/15/16 3:14 PM, Flávio Alves Granato wrote: > On 15-01-2016 14:19, iannsp wrote: >> Eu não consigo enxergar beneficios em ser "multi database" a não ser >> aumentar as possiblidades de venda, salvo casos em que esse é o papel do >> software (orquestrar varias sgdb engines) > Não quer dizer que não exista. cite algum beneficio não comercial que exista em selecionar um tecnologia e ignorar as caracteristicas únicas que você utilizou para definir sua escolha.
>> O paradoxo esta em que, ao tentar se livrar de um acoplamento a um banco >> de dados especifico durante o projeto para aumentar as vendas a equipe >> acaba desenvolvendo mais código, logo, mais bug, logo, mais queijo com >> menos queijo. > Imagino que nas procedures, modelagens e afins de sua bem feitoria não > há mais queijos com menos queijo. Eu faço escolhas baseado em tirar o melhor de cada tecnologia ao inves de ignorar o que há de melhor na tecnologia que escolho. > > O quão custoso/flexível seria alterar o sistema? Já presupondo que tudo > esta implementado no sgbd. Implementado no SGDB ou fora dele o custo é dado pela resistencia a mudanças que a arquitetura utilizada define. No caso do sgdb, principalmente o postgresql que suporta tipagem dos parametros, sobrecarga de metodos, multiplas linguagens de programação e níveis de segurança(acesso ao O.S.) creio que a resistencia da arquitetura é baixa portanto que desenvolvido por um profissional que saiba o que é arquitetura de software, entenda do nicho em que o software que esta escrevendo esta inserindo e pratique simplicidade sem simplismo. > > Minha pergunta ocorre porque acho que sou o único desenvolvedor do grupo > que é desenvolvedor 110% do tempo e anda por aqui há um bom tempo pra > tentar encurtar esta distância entre banco de dados e programadores. Sim, 7 bilhoes de pessoas no mundo. Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open source do mundo. Que acaba de ser anunciado como engine para um noSQL. E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor, mas com aquele 1%... > > Visto que no ambiente de desenvolvimento a gente consegue encurtar a > distância junto ao negócio com ferramentas como a Fitnesse do Tio Bob e > em SGBDs como seria? Testes de aceitação são a exposição de um problema. Pense lean. > > Quando ocorre este tipo de afirmação ou pergunta em alguma parte da > terra é porque alguém ou foi questionado ou ouviu alguém falar sobre o > assunto e não concorda em ser um "mero" repositório ou uma "mera" casca > de apresentação ( no caso dos programadores ). Esquecem de atentar que o > sistema só importa para o cliente e que para o cliente o sistema é tudo > e tudo tem que andar em sinergia, não importando onde esteja as regras > mas onde seja mais fácil, rápido e confiável o seu ajustes. O melhor software que você já escreveu para um cliente é aquele que você não precisou escrever pq entendeu o problema e resolveu sem uma linha de código. Se você quer resolver o problema do seu cliente você deveria repensar o seu 110%. > > A impressão que tenho como desenvolver é que para quem trabalha com > banco de dados, as regras de negócio são estáticas e imutáveis e o que > vejo é que talvez não seja assim para todas as empresas, talvez as > grandes e com processos definidos ( que é raríssimo diga-se de > passagem), agora para o mercado brasileiro que temos algo perto de 95% > de micro e pequenas empresas, segundo o IBGE na época do meu TCC há 15 > anos atrás, é um pouco diferente e as coisas mudam rapidamente logo > temos que acompanhar, do termo "temos" o sistema inteiro. "quem trabalha com banco de dados" soou preconceituoso. "Empresas grandes ou pequenas", não importa: Se elas tiverem programadores dedicados 110% a programar elas terão os mesmos problemas. "Mercado brasileiro": tem mais gente nessa lista com experiencia internacional do que você imagina e quanto mais cenarios você conhece melhor habilitado para analisar o proximo cenario você estará. "as coisas mudam rapidamente": Ué, modele as mudanças. Se os dados não fossem considerados mutaveis talvez a profissão de DBA nem existisse. "temos que acompanhar, o sistema inteiro". Não confunda praticas ruins de programação com programar. > > > _______________________________________________ > 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
