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.
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? ).
No fundo não respondeu à minha pergunta.
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.
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.
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.
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?
"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.
"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.
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... :-)
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
