Em 10 de junho de 2016 14:03, Guimarães Faria Corcete DUTRA, Leandro
<[email protected]> escreveu:
> 2016-06-09 23:32 GMT-03:00 Tiago José Adami <[email protected]>:
>>
>> Na verdade a maioria que conheço critica sem nunca ter usado e
>> defendem o modelo relacional/SQL para tudo. Radicais "SQLtremistas".
>
> Isso existe.  Mas veja que você está confundindo o modelo relacional
> com SQL; um é um conceito, outro uma implementação.  O que me parece
> que talvez alguns desses extremistas que acusam talvez tenham uma
> melhor compreensão das questões que a tua.

Antes fosse... mas no caso criticam porque não conhecem NoSQL e/ou têm
medo de perder seus empregos com SGBDR.

> Tentando explicar melhor: o SQL tem limitações, sim.  Mas o modelo
> relacional, não: o SQL tem várias restrições em relação ao modelo
> relacional, que é capaz de faze tudo o que se pode fazer com dados,
> por ser a única teoria de dados validada até hoje — na verdade, tem a
> dos grafos também, mas é muito mais limitada e complexa.
>
> Como já se disse à exaustão nesta lista e noutras, o que o NoSQL
> contribui é com técnicas de armazenagem e (ou) recuperação que,
> tipicamente, uma vez validadas, o PostgreSQL (e por vezes algum outro
> SGBD SQL) pode incorporar.  Talvez no final das contas as limitações
> inerentes ao SQL se tornem suficientemente importantes, e o
> conhecimento sobre o modelo relacional suficientemente amplo, para que
> abandonemos o SQL em favor de algo puramente relacional, o que
> facilitará ainda mais a incoroporação das técnicas de armazenagem e
> recuperação gestadas fora do mundo SQL.
>
> Pelo jeito, está na hora de lançar novamente meu desafio: quem critica
> o modelo relacional geralmente não o compreendeu.  E no Brasil há
> pouquíssimas pessoas que o aprendem na escola, porque geralmente ou os
> próprios professores não aprenderam, ou foram corrompidos pelas
> vantagen$ de se trabalhar com os fornecedores de sistemas
> proprietários SQL, infelzimente.  Portanto, vós que defendeis o NoSQL,
> desafio-vos: por favor, definam o que é o modelo relacional.
>
> E quem tiver tentado responder, acertado ou não, recomendo ler o
> artigo do Codd em que ele o delineia
> <https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf‎>, para ver a
> que situação ele respondeu ao criá-lo.  Quase meio século atrás.
>
> Por outro lado, minha crítica ao NoSQL é que, ao propagandear suas
> técnicas de armazenagem e recuperação, esquece-se de tudo o que o
> modelo relacional resolveu, como fica óbvio no caso em tela, e
> reinventa-se a roda mal e porcamente.  Ganha-se muito mais ao
> usarem-se essas técnicas no PostgreSQL, como demonstra uma simples
> busca <http://google.com/search?q=nosql+postgresql>.  Dependendo da
> situação, até o @#%$$%!#@$% do MySQL supera o NoSQL
> <http://blog.wix.engineering/2015/12/10/scaling-to-100m-mysql-is-a-better-nosql/>!
>
> Ou seja, trocando em miúdos: NoSQL é útil para quem tem uma
> necessidade que o PostgreSQL _ainda_ não cobre.  Como foi o caso de
> grandes provedores de serviço, mas dificilmente é o de alguém desta
> lista.  E mesmo para esses, a tendência é regularizar com o PostgreSQL
> ou algum outro SQL.  Só para dar mais um exemplo, o Google
> praticamente inaugurou essa moda com o famoso /map-reduce/; hoje, usa
> um serviço SQL sobre uma base (quase-)relacional, o F1 e o Spanner.  O
> Yahoo fez isso antes, com o Himalaia, baseado no PostgreSQL.

Além do teu desafio eu sugiro algo que possa direcionar os
profissionais (programadores, analistas e afins) que pensam em
primeiramente usar NoSQL sem conhecer melhor a implementação
relacional dos SGBDR. Seria viável? Puxando a brasa para o PostgreSQL,
criando tópicos incluindo tudo o PostgreSQL implementa que supre a
necessidade de uso do NoSQL, e também tudo o que não implementa.

Precisaríamos de pessoas que conhecem bem os dois lados da moeda. Tem
alguém disponível aqui na lista?


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a