Il giorno sab, 28/11/2009 alle 14.00 +0100, Enrico Franchi ha scritto: > > On Nov 28, 2009, at 1:03 PM, Federico wrote: > > > Grazie per le risposte, ho scritto "poi" proprio per quello in > > quanto > > sarà una cosa futura. Mi interessa la scalabilità di un prodotto, ma > > non > > sarà la rubrica ad avere tera byte di dati ma bensì un progetto > > futuro. > > > Avevo dimenticato i tag <irony></irony>. Vabbe', sarebbero serviti. > > > Stavo cercando qualche guida, non conosco postgress non l'ho mai > > utilizzato, esiste qualche ottima guida per python e postgress in > > giro??Se si mi passereste il link?? > > Permetti un po' di franchezza? IMHO tu non hai le idee chiare. > Maneggiare terabyte di dati non e' frequente. Oltretutto bisogna > vedere > sono terabyte di dati *strutturati* o meno. Insomma, se avrai esigenze > di que tipo le avrai in futuro e si spera saprai cosa fare o ti > pagherai > una consulenza.
> La maggior parte delle persone non hanno quel tipo di esigenze. Seguo aziende che hanno anche più di un tb di dati, sto passando ad un linguaggio di programmazione come python per poter offrire servizi su diverse piattaforme, in quanto le soluzioni che propongo vanno bene per windows e mac. > Abbandona l'idea di un prodotto che vada bene per tutti i gusti. > Non e' sensato pretendere un DB che scali bene verso l'alto > e verso il basso, e magari sia pure comodo dal punto di vista del > deployment. Non è il deployment che mi preoccupa ma che risponda a determinate esigenze. > > > Postgres e' un ottimo DB, aderisce agli standard, e' ben supportato. > Scala anche in modo eccellente verso l'alto. Ma certe cose non le > fa comunque *nessun* db relazionale in modo efficiente senza passare > per > strumenti terzi, che dovresti studiare e imparare a suo tempo. > > > Ma per una rubrica io userei SQLite, a meno che lo scopo non sia > quello di imparare (o migliorare) il tuo SQL. Nel caso userei proprio > postgres. La rubrica è solo un esercizio, per me il tempo è denaro quindi se devo imparare ad utilizzare un db imparo direttamente quello che nel tempo mi offre migliore scalabilità. Quindi andrò direttamente con postg > Hai bisogno di libri sul modello relazionale, come l'ottimo SQL and > Relational > Theory di Date? Poi te la cavi con la guida di postgre che trovi sul > sito. Su, non > cercare troppo la pappa. :) Non cerco la pappa pronta (di solito cerco prima di arrivarci da solo, poi chiedo consiglio e se non capisco nemmeno cosi cerco di farmelo spiegare) altrimenti avrei chiesto direttamente di dirmi come devo fare la connessione con un db, avrei fatto prima, mentre ho solo chiesto se qualcuno conosceva un ottima guida e poteva dirmi quale, l'avrei studiata come sto facendo per il resto. Mi dispiace se ho chiesto troppo. > > > Per far parlare python con un db e' piu' o meno sempre la solita zuppa > e > una strafaq. O usi le api di DBAPI o usi l'orm del tuo framework o usi > SQLAlchemy. Negli ultimi due casi suggerisco di farsi un'idea dei > pattern > architetturali coinvolti (sull'ottimo libro di Fowler). *MA* li > lascerei perdere > del tutto se quello che vuoi fare e' imparare/migliorare il tuo SQL. Quel poco che ho trovato non mi ha soddisfatto molto, probabilmente ho cercato male allora. Probabilmente per te quello che ho chiesto era una cosa cretina e scontata per me invece no, ho chiesto dei semplici consigli in quanto sono completamente nuovo su python e il mio obbiettivo è quello di imparare il più possibile e nel minor tempo possibile. Grazie per l'aiuto veramente spero un giorno di poter ricambiare Mi sono dilungato un pò giusto per chiarire dei punti. Buon proseguimento Federico _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python