2013/9/19 Dickson S. Guedes <[email protected]>: > Em Qua, 2013-09-18 às 10:13 -0300, Guimarães Faria Corcete DUTRA, > Leandro escreveu: >> 2013/9/18 Flavio Henrique Araque Gurgel <[email protected]>: >> > Eu realmente não entendo porque programador acha SQL difícil. É uma >> > linguagem simples e evita uma porção de erros, o que o autor desmistifica. >> >> Mudança de paradigma. Poucos programadores têm aula de programação >> para além do procedural […] > > Lembrando que NoSQL é algo mais para "Not only SQL".
Já li essa tentativa de mudança de rumo. Mas comigo não colou. Veja, esse povo do NoSQL nunca entendeu de modelos de dados. Nem os teóricos (relacional, grafos), nem os práticos (esquemas). São programadores. Vêem um problema, pensam em como solucioná‐lo, e ignoram toda a história de quem já lidou com eles. E ignoram que o modelo relacional, sendo lógico, pode fazer uso de seja lá qual for o algoritmo (implementação física) que inventarem. Como já tem acontecido com as versões proprietárias do PostgreSQL como o Yahoo! Himalaya, o Greenplum, o Aster… e agora, Google F1 e Spanner. Essa estória ganhou fama basicamente porque juntou a fome com a vontade de comer. No caso, a vontade de comer é essa ‘síndrome do não inventado aqui’, que a cada poucos anos tem gerado tentativas de avançar por meio de regressões à pré‐história prerrelacional: multivalores, OO, até LDAP já foi proposto como sucessor do modelo relacional; e a fome foi a necessidade do Google de usar o algoritmo de mapear e reduzir. Vejam que o povo do Google, que não é tão estúpido quanto nosso setor prostituído da Informática em geral, já está evoluindo para incorporar esse e outros algoritmos no modelo relacional: vide F1 e Spanner (nunca lembro qual é o relacional, qual é o SQL dentre esses dois). É diferente de quando alguém decide não usar um SGBD SQL porque, entendendo as conseqüências, decide que não precisa das vantagens do modelo relacional. Já vi casos, como o Yahoo! Stores criado pelo Paul Graham ou um sistema de bilhetagem programado em /shell/ por um amigo… > E quanto a paradigmas, aquele que consegue pensar diferente do paradigma > orientado-a-objeto e incorpora, por exemplo, um outro paradigma como o > de uma linguagem funcional ou lógica, é bem capaz de compreender o > paradigma SQL CQD. Mas acho que chamar OO de paradigma é um certo otimismo: não há definição clara para muitos detalhes importantes, principalmente nas interfaces com dados, e os benefícios são duvidosos. Vide que o Alan Kay, praticamente o criador de OO, já evoluiu muito depois disso, e as vantagens que OO tem aplicam‐se basicamente na comparação com a programação procedural, não às evoluções sejam funcionais, lógicas, de pilhas, ou reflexivas (aliás, reflexividade se não me engano foi para onde foi o Kay). E a maior parte das pessoas continua programando Basic em Java… como antigamente programavam Cobol em Pascal… Resumindo, a maior parte dos programadores tem dificuldade, sim, de entender tanto OO quanto SQL, mesmo quando programa Java e SQL. Daí verem as camadas de mapeamento como ganho, quando geralmente são perda. > sem problemas e utilizá-lo para excelentes fins, inclusive > utilizando vários linguagens de paradigmas diferentes para as situações > que melhor se encaixem. Saber usar determinada linguagem onde, quanto, > como e por quê, pode ser fator determinante no resultado final. Alguém disse o contrário? > Um carpinteiro não utiliza apenas serrote. Claro. Mas um serrote é uma ferramenta, não uma teoria. Ele se compara não ao modelo relacional, mas (por exemplo) a um algoritmo como o de mapear e reduzir, ou a um SGBD prerrelacional como qualquer NoSQL da vida. Que mensagem mais sexta‐feira… viajei. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
