Bom dia a todos! Pessoal, atualmente sou desenvolvedor, mas ja tive experiencias com PL\SQl com oracle entre outras e foram bem boas, principal ponto forte foi performance, porém percebi alguns pontos que me levaram a crer que podemos dividir as responsabilidades e deixar de pensar que a regra deve ficar so em um lado.
O ponto que me deixou menos favoravel a deixar regras em banco foram as repetições de código, visto que quando à uma mudança de regra fica mais complicado dar manuteção e mudanças são muito comuns ao se desenvolver um software, outro ponto foi a questão de que toda requisição necessáriamente chega ao banco de dados e dependendo do numero de requisições isso pode se tornar um gargalo. Onde trabalho atualmente utilizamos Postgres + SQLSERVER + Mongo, imagina deixar a regra em banco, como seria? Nem consigo imaginar uma solução para reaproveitar a regra em vários bancos sem aumentar a duplicação de código e consequentemente dificultar a manutenção. Utilizamos ORM e funciona muito bem, não apenas para cruds. Não vejo problema algum utilizar uma ORM aproveitando seus pontos fortes e o que ela não atender fazer uma SP, Function, PL, etc. No final estamos todos querendo fazer um bom sistema e tudo que for utilizado para alcançar um bom resultado me parece válido. Em 18 de janeiro de 2016 10:36, iannsp <[email protected]> escreveu: > > > On 1/18/16 10:10 AM, Flávio Alves Granato wrote: > > On 15-01-2016 22:21, iannsp wrote: > >> Implementado no SGDB ou fora dele o custo é dado pela resistencia a > >> mudanças que a arquitetura utilizada define. > > Pode explicar melhor este conceito? Ficou muito vago. > O que manda na capacidade de um software em ser alterado no ritmo que a > equipe de negócios precisa mudar é o quanto a arquitetura é capaz de > suportar mudanças nesses pontos. > Uma arquitetura desenvolvida por alguém que desconhece uma área de > negócios normalmente falha em suportar esses hubs de mudança e ai surge > o cenário em que o desenvolvedor luta com o software legado para > encaixar as mudanças. Isso é oq ue chamo taxa de resistencia a mudança > em uma arquitetura de software. > > > > >> 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. > > "Creio", "simplicidade" e "simplismo" são palavras que levam a um > > entendimento muito subjetivo e apoiado na experiência pessoal de cada > > um. Entender de nicho não deve ser levado em consideração, mas como um > > adicional pois se contrato um desenvolvedor/DBA eu espero que ele faça > > muito bem é sistemas e que as regras de nicho fiquem muito bem entendida > > pelo negócio, aliás é um dos princípios do SOA ( já falaram por ae que > > SOA não é sistema nem procotolo? ). > Pois bem, com todo o respeito: discordo completamente. > Levar o profissional técnico conhecer de técnica sem conhecer o > contexto é contra o que acredito. > DDD e lean, conceitos que uso no desenvolvimento de sistemas, se > referem a isso. > Sim, as palavras creio, simplicidade e simplismo são de aplicação > pessoal, mas não são de meu uso exclusivo e tampouco são subjetivas. > > > > > No fundo não respondeu à minha pergunta. > entendo. > >> Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open > >> source do mundo. > > Concordo contigo, uso ele há mais de 15 anos, mais firme em minha > > memória tenho a versão 7.3 que não me lembro quando foi lançada. > puxa. > >> E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor, > >> mas com aquele 1%... > > não entendi. As vezes tenho dificuldades para entender o sacarmos. > entendo. > >> Testes de aceitação são a exposição de um problema. Pense lean. > > Pensar "lean" seria desenvolver sem testes e principalmente sem permitir > > aos donos do negócio ter controle sobre as regras e não deveríamos expor > > este problema? Como você responde subjetivamente, me permite endenter > > subjetivamente. > >> > >> 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. > > Não entendi, se na primeira resposta você me diz que o arquiteto tem que > > entender do nicho para poder ser um bom profissional. Estranho virou um > > paradoxo. > é necessario entender de negócio para resolver um problema sem programar. > > >> Se você quer resolver o problema do seu cliente você deveria repensar o > >> seu 110%. > > talvez. > >> "quem trabalha com banco de dados" soou preconceituoso. > > Como se os teus 110% não tivesse sido. Mera formalidade de uma discussão > > acalorada não leve a mal. > >> "Empresas grandes ou pequenas", não importa: Se elas tiverem > >> programadores dedicados 110% a programar elas terão os mesmos problemas. > > Como mudar esta realidade? > Parar de acreditar que todo problema exige código em sua solução e que > programar mais resolve mais problemas. É a famosa parabola do velho > lenhador, aqui tem um video para ilustrar melhor: > https://www.youtube.com/watch?v=RGHs8zgZMh0 > > >> "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á. > > Sim, conheço alguns. Já preambulo por esta lista há uns 12 anos. Não é > > de hoje que vejo a discussão de onde ficar as regras de negócio e não é > > a primeira vez que entro nela. Só ler o histórico da lista. ;-) > > > > A diferença que hoje não acho que deva ficar em lugar algo, ou melhor > > dizendo que é melhor estar em algum lugar porque X ou Y disse, como você > > comentou o pragmatismo do movimento Lean leva a se adaptar o tempo todo. > > Na minha concepção o modelo relacional, mesmo que ainda claudicante no > > PostgreSQL e isso não o desmerece pois os outros bancos de dados são > > pernetas mesmo, é a melhor saída para manter a unicidade dos dados, mas > > tem outras respostas que preciso dar quando falamos de sistemas para > > clientes finais, como em uma tela de formulário de cadastro por exemplo > > de um paciênte médico em que eu tenha que colher muitas informações > > sobre a saúde dele e até dados pessoais ( poiseh as vezes que imaginou o > > formulário pecou no design da informação ), o retorno para a tela como > > seria? Dar raise campo a campo não parece ser uma opção muito otimizada > > e "eu" não a escolheria. > > > Entendo a sua questão: Suportar uma modelagem de um problema que esta em > constante evolução é um desafio comum para um DBA e para um > desenvolvedor, mas isso não tem a ver com regras de negócio mas sim com > modelagem e suportar uma modelagem assim pode ser algo simples no > postgreSQL, principalmente se você utilizar um campo json ou jsonb. > Agora, se você quiser modelar o problema de maneira relacional basta > suportar as entidades em separado e modelar tabelas para cada uma delas > e permitir relacionamentos 1->N. > > Claudicante é tudo que o modelo relacional não é nem no PostgreSQL nem > nos outros bancos de dados relacionais ou objeto relacionais. > > >> > >> "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. > > Fiz várias perguntas e agora que consegue me dar alguma resposta mais > > assertiva? E aliás, só peguei o teu email como exemplo e não foi > > direcionado a você a não ser as 2 ou 3 primeiras linhas. > >> "temos que acompanhar, o sistema inteiro". Não confunda praticas ruins > >> de programação com programar. > > É prática comum em algumas instituições religiosas a pinçagem de > > palavras ou parte de frases para poder se apoiar e atacar, se conseguir > > ser mais assertivo nas tuas respostas ia ajudar bastante nas discussões. > > > Não tem como ser mais assertivo por que a asserção esta no kit de > conhecimento que você usa para a interpretação. > > > Senhores já que fomos advertidos, não respondo(do verbo fazer ou > > retrucar) mais emails que tenham tom emocional e direto, há não ser que > > já conheça a pessoa e saiba que ela reagira bem há uma crítica. Para > > evitarmos os flames mesmo... :-) > Não considerei nossa troca de emails como um flame. Você não me ofendeu, > eu não te ofendi. Surgiram aqui e acolá algumas coisas boas nessa troca > de email. > > > > _______________________________________________ > > 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 > -- Atenciosamente, Felipe Moura Desenvolvedor http://about.me/felipewebdf twitter: @felipewebdf talk: [email protected] (61) 8490-8156 *Não é da benevolência do padeiro, do açougueiro ou do cervejeiro que eu espero que saia o meu jantar, mas sim do empenho deles em promover seu "auto-interesse".*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
