NosqlDay
25 - 26 Mar 2011
at Novotel
Talk comments
bravo luca, anche se gia conoscevo il prodotto e' stato comunque molto interessante
la parte finale, di Federico, e' stata molto interessante, almeno per il potenziale mostrato; probabilmente andava accorciata la prima sulla quale credo che molti avessero i pre-requisiti adeguati per non dovervisi soffermare troppo
ottimo talk, peccato per la collocazione oraria
Non mi ha coinvolto particolarmente, ma andando verso la tarda mattinata la stanchezza dei 3 interventi precedenti si e' fatta sentire.
Ottima cosa l'essersi messi in gioco col codice, anche se come qualcuno ha gia evidenziato mancava qualche elemento "for real".
Un genio, punto e basta.
Mi ha coinvolto veramente poco.
Non credo sia stata una marketta ( perlomeno non spinta... ) ma mi sono trovato in estremo disaccordo con alcune frasi pronunciate, che al solito scatenano la guerra di religione verso la quale un talk non dovrebbe mai andare: credo sia uno dei punti di partenza per ogni speaker.
Gabriele Lana esordisce parlando di "un martello e tutti chiodi" e in questo talk JSON viene paventato come il formato definitivo... Se tutti i sistemi NoSQL usano JSON *non* vuol dire che esso sia la soluzione a *qualsiasi* problema.
Di for real, peraltro, abbiamo visto poco o nulla, per cui il talk mi ha lasciato l'amaro in bocca.
Sfortunato Percoco che ha dovuto condensare la sua parte in pochissimi minuti: probabilmente, dovendo parlare nello specifico di Mongo, la sua parte sarebbe stata un plus.
Non so quanta esperienza avessero gli speaker in tema conferenziero, magari si e' semplicemente pagata la tensione della conferenza: anche se il talk, in definitiva, non mi e' piaciuto, non me la sento di liquidarlo malamente, ci puo' stare.
ottimo intervento, e' servito sicuramente molto riflettere meglio sui limiti cui ci affacciamo attraverso gli antipattern
+1 per maraspin
presentazione densa di contenuti di valore
Una domanda che mi è sorta durante l'interessante talk: qual'è il caso migliore per usare un DB relazionale? Si è visto che se i dati sono molto "relazionali", si rischia di dover fare troppe join (in questo caso è consigliabile un db a grafo). Il caso diametralmente opposto è quello dell'alieno, da evitare anch'esso con un db relazionale (meglio un key value alla redis probabilmente). Si può dunque concludere che la soluzione sta nel mezzo?