<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 28, 2009, at 1:03 PM, Federico wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Grazie per le risposte, ho scritto "poi" proprio per quello in quanto<br>sarà una cosa futura. Mi interessa la scalabilità di un prodotto, ma non<br>sarà la rubrica ad avere tera byte di dati ma bensì un progetto futuro.<span class="Apple-converted-space"> </span><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></span></blockquote><div><br></div><div>Avevo dimenticato i tag <irony></irony>. Vabbe', sarebbero serviti.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Stavo cercando qualche guida, non conosco postgress non l'ho mai<br>utilizzato, esiste qualche ottima guida per python e postgress in<br>giro??Se si mi passereste il link??</span></blockquote></div><br><div>Permetti un po' di franchezza? IMHO tu non hai le idee chiare.</div><div>Maneggiare terabyte di dati non e' frequente. Oltretutto bisogna vedere</div><div>sono terabyte di dati *strutturati* o meno. Insomma, se avrai esigenze</div><div>di que tipo le avrai in futuro e si spera saprai cosa fare o ti pagherai</div><div>una consulenza.</div><div><br></div><div>La maggior parte delle persone non hanno quel tipo di esigenze. </div><div><br></div><div>Abbandona l'idea di un prodotto che vada bene per tutti i gusti. </div><div>Non e' sensato pretendere un DB che scali bene verso l'alto </div><div>e verso il basso, e magari sia pure comodo dal punto di vista del</div><div>deployment.</div><div><br></div><div>Postgres e' un ottimo DB, aderisce agli standard, e' ben supportato.</div><div>Scala anche in modo eccellente verso l'alto. Ma certe cose non le </div><div>fa comunque *nessun* db relazionale in modo efficiente senza passare per</div><div>strumenti terzi, che dovresti studiare e imparare a suo tempo.</div><div><br></div><div>Ma per una rubrica io userei SQLite, a meno che lo scopo non sia</div><div>quello di imparare (o migliorare) il tuo SQL. Nel caso userei proprio</div><div>postgres.</div><div><br></div><div>Hai bisogno di libri sul modello relazionale, come l'ottimo SQL and Relational</div><div>Theory di Date? Poi te la cavi con la guida di postgre che trovi sul sito. Su, non</div><div>cercare troppo la pappa. :)</div><div><br></div><div>Per far parlare python con un db e' piu' o meno sempre la solita zuppa e </div><div>una strafaq. O usi le api di DBAPI o usi l'orm del tuo framework o usi</div><div>SQLAlchemy. Negli ultimi due casi suggerisco di farsi un'idea dei pattern</div><div>architetturali coinvolti (sull'ottimo libro di Fowler). *MA* li lascerei perdere</div><div>del tutto se quello che vuoi fare e' imparare/migliorare il tuo SQL.</div><div><br></div><div><br></div></body></html>