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. > >> Isso não seria um >> /*caveat/* por obrigar aos programadores a aprender toda a teoria >> relacional, já que muitos mal compreendem a SQL? > > Pelo contrário, o modelo relacional é mais simples que o SQL. Muito > mais simples. Não é necessário aprender toda a teoria por trás > (teoria dos conjuntos, lógica dos predicados). 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. >> - Ao que vi, a SQL nada mais é que uma extensão, o acesso aos dados >> será feito inicialmente por uma API. Como seriam tratadas as falhas da >> SQL - que você mesmo menciona várias vezes na lista. Talvez houvesse a >> preferência seria por utilizar a extensão SQL ao invés da API, dada a >> grande portabilidade existente hoje - e facilidade de compreensão em >> relação às expressões em A.R. > > Não foi isso que entendi… entendi que o Spanner é o mecanismo de > armazenamento, que diz não ser relacional mas parece, e F1 é o SGBD > SQL criado sobre o Spanner. Hmmm... agora começa a fazer sentido. > >> - Há uma perda de desempenho na gravação para obter desempenho na >> leitura. Eu diria que com uma view materializada haveria o mesmo >> comportamento. Mas ainda assim o desempenho é menor que o MySQL. >> Parece que não houve vantagem até o momento no ponto de vista >> desempenho - talvez se usassem PostgreSQL... :) > > O problema deles não é desempenho, é escalabilidade. E eles dizem ter > resolvido o problema do desempenho usando tipos ricos, mais um ponto > relacional. Sim, isso deu pra entender. Só foi um ponto que achei interessante salientar. > >> - 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. > >> Por fim... se eu falei besteira e não entendi, me desculpe e corrige >> aí, ou pelo menos dá seu ponto de vista. Apesar de algumas >> funcionalidades apresentadas parecem ter algum sentido/vantagem, eu >> ainda diria que é cedo para pensar no F1 como a solução dos problemas >> ORM (e todas suas variações) X SGBD "Relacional" X Álgebra Relacional. > > Nah, o F1 é SQL. O Spanner é que me atraiu de verdade; o F1 parece só > ser uma abordagem fisicamente diferente para mais ou menos os mesmos > problemas tratados pelo PostgreSQL. Pois é, mas em que sentido seria uma melhor alternativa se vai acabar usando SQL? Ou a sua idéia com esse post foi incitar à inclusão das boas funcionalidades existentes no PostgreSQL? >> Talvez sua complexidade não seja atraente. > > Que complexidade? A implementação de qualquer maneira é particular à > infraestrutura da Google. 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. -- TIAGO J. ADAMI http://www.adamiworks.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
