2009/4/14 salvatore monaco <salvatore.mon...@gmail.com>: > io uso mysql ma postgres non e' da meno come potenza scalabilità e > performance > ma qualsiasi sia la scelta che tu voglia fare a livello di database sappi > che devi padroneggiare tutto lo scibbile del db per poter avere il meglio.
Non esageriamo. Capisco dire che bisogna padroneggiare i db, su questo sono d'accordo. Ma per me padroneggiare lo scibile dei db ha un significato un po' eccessivo. Tipicamente la distribuzione fisica dei dati su disco (organizzazione a livello di cilindri, per dire), le strategie implementative per gestire failures hardware e ricorstruire a partire da dati corrotti, implementare indici, multi-indici, implementare in modo efficiente b-tree, hash-tables, obdd, scrivere un'ottimizzatore per query SQL (o in generale ottimizzare espressioni dell'algebra relazionale), la conseguenze ottimizzazione dei piani per l'esecuzione delle query la memorizzazione efficiente di righe, implementazione di varie politiche di undo/redo, e colonne su disco a seconda dell'efficienza che si vuole ottenere, magari in ambiente distribuito e parallelo... beh, tutta sta roba fa parte dello scibile dei db, ma direi che e' abbastanza sovradimensionata per scrivere un gestionale, visto che interessa a chi scrive un DBMS e non chi lo usa. Qualche fondamento e' utile per capire le questioni di efficienza (per dire sapere come si implementano gli indici puo' essere molto utile per progettarli in modo efficiente lato utente), ma in generale potrebbe essere un overkill per un gestionale con Django. > per quanto riguarda GUi io prediliggo per adesso il web con django ma se > devi sviluppare e scegliere un toolkit grafico vale la stessa regola per i > db Si, anche io suggerirei un gestionale GUI based nella maggior parte dei casi. Testare le web-ui se non esageri e' piu' facile che testare le UI classiche, IMHO. > sono tutti strumenti accellenti ma bisogna conoscerli con profondità per > averne il meglio. > ho visto cose fatte con tkinter da paura.... Quoto, ovviamente. Tkinter e' solo un po' bruttarello di default (e IMHO rispetto certe librerie come Cocoa e Qt *rimane* bruttino), ma pre il resto fa il suo mestiere. > usa da subito un software per il versionamento del codice csv o svn vanno > benissimo CVS io lo schiverei ormai. SVN fa il suo mestiere. Ultimamente sono innamoratissimo di Perforce. Per stare su roba open, io userei mercurial. > parti da delle specifiche funzionali , carta e penna e diagrammi di flusso > sono molto piu' importanti della scelta del db o del toolkit grafico > e non dimenticare che la forza di un buon progetto e' la struttura del Db > pensa bene a come organizzare i dati tabelle, le stored procedures e i > trigger per far fare al db il lavoro che altrimenti faresti fare a > python(l'ho imparato con ORACLE, plSQL a manetta) . Qui invece sono abbastanza in disaccordo. Premessa: io sono un forte fautore di metodi agili di sviluppo. Sono fortemente convinto che il big-design up front sia un ottimo modo per avere un cattivo progetto. Questo e' diverso da dire che *non* ci deve essere design, eh. Non so comunque se sia il caso di insistere qui sulle metodologie di sviluppo. OP potrebbe essere ferrato in questo e semplicemente non avere esperienza con lo sviluppo Python, per cui fare una discussione su XP potrebbe essere solo fuori luogo. <http://www.extremeprogramming.org/> Non solo, molte stored procedures sono IMHO evitabili, *oggi*. MySQL ha un supporto limitatissimo, Postgre lo ha migliore, ma rimane sempre un PITA rispetto a scrivere le cose in Python. Hai un certo hit in termini di efficienza, ma e' difficile imbattercisi in un gestionale come quello di OP. Direi anche impossibile, visto e considerato che addirittura non sconsiglierei un ORM. Le SP ti vincolano ad un singolo DB. Potrebbe non essere *necessariamente* la scelta migliore. Io partirei con l'idea di non usarle affatto e la cambierei dopo avere comprovato che semplificano *considerabilmente* le cose. Vedo sotto che parti da una logica di AS400, e questo spiega la tua visione. E non lo dico in senso negativo. Dico solo che cambiando in modo cosi' radicale la piattaforma (qui parliamo di Python + piccolo db su un server win/linux), certe scelte potrebbero essere molto diverse. Nota che debuggare una SP in Oracle e' ben piu' facile che farlo su Postgre o su MySQL. Per il suo progetto io addirittura sarei del parere che il db e' quasi un dettaglio implementativo sottostante il modello ad oggetti. Questo e' in contrasto con la classica visione del problema, ma e' un punto di vista sempre piu' diffuso, specie in questi ambiti. -- -enrico _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python