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. > 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). > (eu por exemplo, > trabalho com SQL a quase 10 anos e até hoje ainda não entendo > completamente o conceito da álgebra relacional); Nem precisa. Mas uma linguagem algébrica é mais simples que o SQL, que mistura cálculo, álgebra e outras coisas mais. > - 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. > - 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. > - Permite o não-uso de ORM com um OM. Que é um OM? > 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. > Talvez sua complexidade não seja atraente. Que complexidade? A implementação de qualquer maneira é particular à infraestrutura da Google. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
