2012/9/12 Flávio Alves Granato <flavio.gran...@gmail.com>: > > Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns > ), basicamente "cada macaco no seu galho".
Mas esse conceito não é válido aqui. Como ele se aplicaria ao caso? Parece mais uma regrinha generalizada… > Me baseio nesta discussão [1] > pois concordo plenamente com a última opinião. Extremamente desinformada, como tentarei demonstrar. > "1. Violação de princípios – Regra no banco viola o principio que > chamamos de Soc (separation os concern) Chamam incorretamente. Separação de aspectos (ou de escopo) é um conceito do Dijkstra. Tanto o autor quanto o conceito são amplamente mal interpretados. No caso, vem de _On the role of scientific thought_ <http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html>. A Wikipædia <http://en.wikipedia.org/wiki/Separation_of_concerns#Origin> cita: ‘Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.’ Para traduzir o essencial: “…para meu gosto é característico de todo pensamento inteligente… dispõe‐se a estudar profundamente um aspecto do sujeito isolado para sua própria consistência, sempre sabendo que se ocupa apenas com um dos aspectos. Sabemos que um programa tem de ser correto e podemos estudá‐lo somente desse ponto de vista; também sabemos que deve ser eficiente e podemos estudar sua eficiência noutro dia, por assim dizer. …o programa é desejável. Mas nada se ganha —pelo contrário!— ao abordar esses vários aspectos simultaneamente. É o que às vezes chamei ‘a separação das preocupações’ que, mesmo não perfeitamente possível, é ainda a única técnica efetiva disponível que conheço para organizar os pensamentos. Isso é o que quero dizer com ‘focar a atenção nalgum aspecto’: não significa ignorar os outros aspectos, é só fazer justiça ao fato de que do ponto de vista deste aspecto, o outro é irrelevante. É ser focado e ter mente aberta simultaneamente.” > 2. Falta de portabilidade – Regra no banco não tem garantias de > portabilidade entre diferentes vendores de SGDB. Certo, mas isso é um problema dos SGBDs proprietários e (ou) ruins, que não implementam os padrões… > Vale lembrar que hoje > SGDB já considerando LEGADO advento do NoSql. O que mostra que o autor é uma toupeira no que se refere a dados, além de não saber escrever. > ## resalto que até a > chegada do PostgreSQL 9.2 - Flávio Granato ## Isso nunca foi verdade. O PostgreSQL 9.2 simplesmente implementa mais tipos, diminuindo ainda mais os já ínfimos casos em que usar algo prerrelacional (que é o que o NoSQL é, no fundo) valia a pena. > 3. Programação Pobre – regras no banco de dados não é OO e nem > funcional, sendo assim não tem como usar recursos como classes, > encapsulamento, agregação, composição, associação, herança e polimorfismo. Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, funcionais e até OO e funcionais. > 4. Performance Ruim – soluções com grande numero de acessos simultâneos > podem facilmente derrubar um SGDB, uma vez que um banco de dados não tem > todos os gerenciamentos de recursos e as otimizações devidas encontradas > em MIDDLEWARE como resources pooling, passivation, clustering, etc…" por > Fernando Franzini. Outra inverdade. Vide, por exemplo, pg_pool e XC. > estou com um projeto nas mãos que > tudo, literalmente tudo é uma procedure no banco, desde inserts a > updates e selects mais "trabalhosos" e digo que não é nada produtivo E isso nada tem a ver com a lógica estar na base. A lógica deve ser preferencialmente declarativa, e só quando limitações seja no padrão SQL, seja em nossa implementação, impedirem implementar declarativamente é que se deve recorrer a procedimentos. O uso generalizado de procedimentos indica falta de conhecimento. > pois tudo tem que se criar uma procedure e desenvolver, "se" fosse por > conta do desenvolvedor orientado pelo DBA ( em nosso projeto não existe > mais o chapéu de DBA ) seria muito mais produtivo, pois paralelizaria o > desenvolvimento e não concentraria somente em uma pessoa, estamos > falando de equipe pequena 4 pessoas e de uma empresa que seu fim é > desenvolver software para outras empresas. Não sei se me fiz entender bem. Esse é apenas um problema de organização, nada tem a ver com o que discutíamos… > Lembro-vos que não estamos discutindo a opinião do Fernando Franzini... > > 1 http://www.tectura.com.br/topics/regras_de_negocio_banco_x_oo Uai, mas se o que fizeste foi colocá‐la na discussão… _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
