Em 12/09/2012 15:57, Guimarães Faria Corcete DUTRA, Leandro escreveu: > 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.” Entendo, mal interpretação minha.
Mas para mim, > > >> 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. Não tem necessidade dessa agressividade, como eu já disse em outro momento, vai existir de tudo sempre, até pessoas que acham que SGBD é legado... > > >> ## 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. concordo. Mas por isso ressaltei... NoSQL é recalque de programador que acha que base de dado deva ser algo burro, do tipo toma e me dá... > > >> 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. Alguém realmente usa? Se o padrão de fato é PL/PgSQL, então concordo e concordo também que é uma generalização, se não usam as linguagens citas como alternativas, ai são outros quinhetos. > > >> 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. Conhecimentos que estou adquirindo, mas em empresas que passei tem adotado escalar a aplicação e não o SGBD. > > >> 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. Concordo e ainda bem que não foi eu, normalmente não o faço assim. Haha... uso ORM... tanto que é o motivo desta thread que abri... não criticar o não uso, mas saber quando é melhor o "não uso" e começo a entender, nem precisa enfatizar que o melhor uso de ORM é nunca, ou ao menos não por enquanto... > > >> 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… esse é uma parte do texto que podemos dizer, enchimento de linguiça nem precisava ser levado em consideração... hehehe > > >> 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… O que eu quero dizer é, o texto é dele e compartilho da opinião, logo as críticas podem ser dirigidas a mim. Não foi bem explicado. Para meu entendimento, o que seria SGBD conter toda a lógica de negócios? Normalmente tenho feito de maneira que o SGBD confirme( check, constraints... ) as regras desenvolvidas na aplicação e não levando a aplicação a ser uma visão da base. _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
