2012/9/21 Tiago Adami <[email protected]>: > Em 21 de setembro de 2012 11:44, Guimarães Faria Corcete DUTRA, > Leandro <[email protected]> escreveu: >> 2012/9/20 Tiago Adami <[email protected]>: >>> >>> - Se pretende realmente implementar o puro aspecto relacional >> >> Não pretende. Pelo contrário, dizem que não. Ma o que usaram para >> dizer que não é, mostra que seria. Não puro, mas mais do que o SQL. > > Então realmente não entendi nada da apresentação. Para mim parece ser > um "repositório" de dados com uma extensão SQL.
Semelhante a SQL, sim. E um repositório, sim. Mas um SGBD SQL mesmo é o F1, e a minha questão é o que o Spanner é exatamente. > Mesmo não conhecendo a álgebra 100% eu diria que suas expressões são > mais complexas que um SQL, mesmo que seja um SQL enorme. Mas isso é > mais opinião que fato. Tem um exemplo de coisas que achas mais complexas em álgebra que em SQL? E há também a alternativa do cálculo. >>> - Permite o não-uso de ORM com um OM. >> >> Que é um OM? > > Nem eu sei! Mas é o que diz no slide 16: Very lightweight ORM - > doesn't really have the "R". Por isso pensei que fosse que o meio de > acesso principal aos dados seria através de uma API. Entendi. /Object mapping/. Mas como o argumento deles para dizer que o Spanner não é relacional me pareceu furado, fica difícil entender a frase sem ver mais detalhes. Talvez não dê mesmo para entender mais, por enquanto. > Pois é, mas em que sentido seria uma melhor alternativa se vai acabar > usando SQL? Tanto o F1 quanto o Spanner são distribuídos numa escala em que ainda não somos. Mas somos livre e estamos disponíveis, o que não é o caso deles para quem está fora da Google. Mas o que achei mais interessante é que o Spanner me pareceu algo que sempre me interessou, um SGBDR. > Ou a sua idéia com esse post foi incitar à inclusão das > boas funcionalidades existentes no PostgreSQL? Não foi a idéia, mas de fato tem um pouco a ver com o que está acontecendo aos poucos, com tipos ricos e com os vários mecanismos de distribuição. > A complexidade de usar uma API ao invés da SQL apenas como extensão - > que poderia não ter todos os recursos existentes, ou simplesmente a > falta de uma linguagem procedural como PL/PgSQL. Mas pelo visto não me > atentei ao primeiro parágrafo da página que leva ao Download do PDF. Entendi. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
